RE: [PATCH] drm/dp_mst: clear time slots for ports invalid
> -Original Message-
> From: Lyude Paul
> Sent: Saturday, December 21, 2019 8:12 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/dp_mst: clear time slots for ports invalid
>
> Mhh-I think I understand the problem you're trying to solve here but I think
> this
> solution might be a bit overkill. When I did the rework of topology references
> for ports, I made it so that we can guarantee memory access to a port without
> it needing to be a valid part of the topology. As well, all parents of the
> port are
> guaranteed to be accessible for as long as the child is. Take a look at:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F01.org%
> 2Flinuxgraphics%2Fgfx-docs%2Fdrm%2Fgpu%2Fdrm-kms-helpers.html%23refco
> unt-relationships-in-a-topologydata=02%7C01%7Cwayne.lin%40amd.co
> m%7C722655b546c049dc081908d785aa6758%7C3dd8961fe4884e608e11a82d
> 994e183d%7C0%7C0%7C637124839257213115sdata=Ctha3ja8kleeFOp
> PpA7EwDV1is81RAMsjqd1P6463ak%3Dreserved=0
>
> It's also worth noting that because of this there's a lot of
> get_port_validated()/put_port_validated() calls in the MST helpers that are
> now bogus and need to be removed once I get a chance. For new code we
> should limit the use of topology references to sections of code where we need
> a guarantee that resources on the port/branch (such as a drm connector, dp
> aux port, etc.) won't go away for as long as we need to use them.
>
> Do you think we could change this patch so instead of removing it from the
> proposed payloads on the CONNECTION_STATUS_NOTIFY, we keep the port's
> memory allocation around until it's been removed from the proposed payloads
> table and clean it up there on the next payload update?
>
Really appreciate for your time and comments in detail.
In this patch, I wanted to just set the proposed_vcpi->num_slots to 0 for those
ports which are no longer in the topology due to there is no need to allocate
time
slots for these port. And expect those vcpi will be updated during next update
of
payload ID table by drm_dp_update_payload_part1().
I tried to use drm_dp_mst_topology_get_port_validated() as a helper to
decide whether a port is in the topology or not. Use this function to iterate
over
all ports that all proposed_vcpi[] drive to. If one port is not in the
topology, set the
num_slots of the proposed_vcpi for this port to 0. With num_slots as 0, these
proposed_vcpi will be clean up in next payload table update by
drm_dp_update_payload_part1(). If a port is still in the topology, then release
the reference count which was acquired previously from
drm_dp_mst_topology_get_port_validated() and do nothing.
I didn't mean to kill invalid ports on receiving CONNECTION_STATUS_NOTIFY.
Sorry if I misuse or misunderstand something here?
> On Fri, 2019-12-06 at 16:39 +0800, Wayne Lin wrote:
> > [Why]
> > When change the connection status in a MST topology, mst device which
> > detect the event will send out CONNECTION_STATUS_NOTIFY messgae.
> >
> > e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
> >
> > Currently, under the above case of unplugging device, ports which have
> > been allocated payloads and are no longer in the topology still occupy
> > time slots and recorded in proposed_vcpi[] of topology manager.
> >
> > If we don't clean up the proposed_vcpi[], when code flow goes to try
> > to update payload table by calling drm_dp_update_payload_part1(), we
> > will fail at checking port validation due to there are ports with
> > proposed time slots but no longer in the mst topology. As the result
> > of that, we will also stop updating the DPCD payload table of down stream
> port.
> >
> > [How]
> > While handling the CONNECTION_STATUS_NOTIFY message, add a detection
> > to see if the event indicates that a device is unplugged to an output port.
> > If the detection is true, then iterrate over all proposed_vcpi[] to
> > see whether a port of the proposed_vcpi[] is still in the topology or
> > not. If the port is invalid, set its num_slots to 0.
> >
> > Thereafter, when try to update payload table by calling
> > drm_dp_update_payload_part1(), we can successfully update the DPCD
> > payload table of down stream port and clear the proposed_vcpi[] to NULL.
> >
> > Signed-off-by: Wayne Lin
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 24
> +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 5306c47dc820..2e236b6275c4 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2318,7 +2318,7 @@ drm_dp_mst_handle_conn_stat(struct
> > drm_dp_mst_branch *mstb, {
> > struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> > struct
Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN
On Tue, Dec 24, 2019 at 06:03:50PM -0800, John Hubbard wrote: > On 12/22/19 5:23 AM, Leon Romanovsky wrote: > > On Fri, Dec 20, 2019 at 03:54:55PM -0800, John Hubbard wrote: > > > On 12/20/19 10:29 AM, Leon Romanovsky wrote: > > > ... > > > > > $ ./build.sh > > > > > $ build/bin/run_tests.py > > > > > > > > > > If you get things that far I think Leon can get a reproduction for you > > > > > > > > I'm not so optimistic about that. > > > > > > > > > > OK, I'm going to proceed for now on the assumption that I've got an > > > overflow > > > problem that happens when huge pages are pinned. If I can get more > > > information, > > > great, otherwise it's probably enough. > > > > > > One thing: for your repro, if you know the huge page size, and the system > > > page size for that case, that would really help. Also the number of pins > > > per > > > page, more or less, that you'd expect. Because Jason says that only 2M > > > huge > > > pages are used... > > > > > > Because the other possibility is that the refcount really is going > > > negative, > > > likely due to a mismatched pin/unpin somehow. > > > > > > If there's not an obvious repro case available, but you do have one (is > > > it easy > > > to repro, though?), then *if* you have the time, I could point you to a > > > github > > > branch that reduces GUP_PIN_COUNTING_BIAS by, say, 4x, by applying this: > > > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > > index bb44c4d2ada7..8526fd03b978 100644 > > > --- a/include/linux/mm.h > > > +++ b/include/linux/mm.h > > > @@ -1077,7 +1077,7 @@ static inline void put_page(struct page *page) > > >* get_user_pages and page_mkclean and other calls that race to set up > > > page > > >* table entries. > > >*/ > > > -#define GUP_PIN_COUNTING_BIAS (1U << 10) > > > +#define GUP_PIN_COUNTING_BIAS (1U << 8) > > > > > > void unpin_user_page(struct page *page); > > > void unpin_user_pages_dirty_lock(struct page **pages, unsigned long > > > npages, > > > > > > If that fails to repro, then we would be zeroing in on the root cause. > > > > > > The branch is here (I just tested it and it seems healthy): > > > > > > g...@github.com:johnhubbard/linux.git > > > pin_user_pages_tracking_v11_with_diags > > > > Hi, > > > > We tested the following branch and here comes results: > > Thanks for this testing run! > > > [root@server consume_mtts]# (master) $ grep foll_pin /proc/vmstat > > nr_foll_pin_requested 0 > > nr_foll_pin_returned 0 > > > > Zero pinned pages! Maybe we are missing some CONFIG_* option? https://lore.kernel.org/linux-rdma/12a28917-f8c9-5092-2f01-92bb74714...@nvidia.com/T/#mf900896f5dfc86cdee9246219990c632ed77115f > > ...now I'm confused. Somehow FOLL_PIN and pin_user_pages*() calls are > not happening. And although the backtraces below show some of my new > routines (like try_grab_page), they also confirm the above: there is no > pin_user_page*() call in the stack. > > In particular, it looks like ib_umem_get() is calling through to > get_user_pages*(), rather than pin_user_pages*(). I don't see how this > is possible, because the code on my screen shows ib_umem_get() calling > pin_user_pages_fast(). > > Any thoughts or ideas are welcome here. > > However, glossing over all of that and assuming that the new > GUP_PIN_COUNTING_BIAS of 256 is applied, it's interesting that we still > see any overflow. I'm less confident now that this is a true refcount > overflow. Earlier in this email thread, I posted possible function call chain which doesn't involve refcount overflow, but for some reason the refcount overflow was chosen as a way to explore. > > Also, any information that would get me closer to being able to attempt > my own reproduction of the problem are *very* welcome. :) It is ancient verification test (~10y) which is not an easy task to make it understandable and standalone :). > > thanks, > -- > John Hubbard > NVIDIA > > > [root@serer consume_mtts]# (master) $ dmesg > > [ 425.221459] [ cut here ] > > [ 425.225894] WARNING: CPU: 1 PID: 6738 at mm/gup.c:61 > > try_grab_compound_head+0x90/0xa0 > > [ 425.228021] Modules linked in: mlx5_ib mlx5_core mlxfw mlx4_ib mlx4_en > > ptp pps_core mlx4_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre > > ip_tunnel rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm ib_uverbs ib_ipoib > > ib_umad ib_srp scsi_transport_srp rpcrdma ib_iser libiscsi > > scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core [last unloaded: mlxfw] > > [ 425.235266] CPU: 1 PID: 6738 Comm: consume_mtts Tainted: G O > >5.5.0-rc2+ #1 > > [ 425.237480] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > 1.10.2-1ubuntu1 04/01/2014 > > [ 425.239738] RIP: 0010:try_grab_compound_head+0x90/0xa0 > > [ 425.241170] Code: 06 48 8d 4f 34 f0 0f b1 57 34 74 cd 85 c0 74 cf 8d 14 > > 06 f0 0f b1 11 74 c0 eb f1 8d 14 06 f0 0f b1 11 74 b5 85 c0 75 f3 eb b5 > > <0f> 0b 31 c0 c3 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
Re: [PATCH 1/2] Return from mtk_ovl_layer_config after mtk_ovl_layer_off
Hi, Mark:
On Wed, 2019-12-11 at 10:49 -0500, Mark Yacoub wrote:
> drm/mediatek: return if plane pending state is disabled.
>
> If the plane pending state is disabled, call mtk_ovl_layer_off then
> return.
> This guarantees that that the state is valid for all operations when the
> pending state is enabled.
For this series, applied to mediatek-drm-next-5.6 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6
Regards,
CK
>
> Suggested-by: Sean Paul
> To: CK Hu
> To: dri-devel@lists.freedesktop.org
> Cc: Daniele Castagna
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 4a55bb6e2213..526b595eeff9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -260,8 +260,10 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp
> *comp, unsigned int idx,
> unsigned int src_size = (pending->height << 16) | pending->width;
> unsigned int con;
>
> - if (!pending->enable)
> + if (!pending->enable) {
> mtk_ovl_layer_off(comp, idx);
> + return;
> + }
>
> con = ovl_fmt_convert(ovl, fmt);
> if (idx != 0)
> @@ -283,8 +285,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp
> *comp, unsigned int idx,
> writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
> writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
>
> - if (pending->enable)
> - mtk_ovl_layer_on(comp, idx);
> + mtk_ovl_layer_on(comp, idx);
> }
>
> static void mtk_ovl_bgclr_in_on(struct mtk_ddp_comp *comp)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN
On 12/22/19 5:23 AM, Leon Romanovsky wrote: On Fri, Dec 20, 2019 at 03:54:55PM -0800, John Hubbard wrote: On 12/20/19 10:29 AM, Leon Romanovsky wrote: ... $ ./build.sh $ build/bin/run_tests.py If you get things that far I think Leon can get a reproduction for you I'm not so optimistic about that. OK, I'm going to proceed for now on the assumption that I've got an overflow problem that happens when huge pages are pinned. If I can get more information, great, otherwise it's probably enough. One thing: for your repro, if you know the huge page size, and the system page size for that case, that would really help. Also the number of pins per page, more or less, that you'd expect. Because Jason says that only 2M huge pages are used... Because the other possibility is that the refcount really is going negative, likely due to a mismatched pin/unpin somehow. If there's not an obvious repro case available, but you do have one (is it easy to repro, though?), then *if* you have the time, I could point you to a github branch that reduces GUP_PIN_COUNTING_BIAS by, say, 4x, by applying this: diff --git a/include/linux/mm.h b/include/linux/mm.h index bb44c4d2ada7..8526fd03b978 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1077,7 +1077,7 @@ static inline void put_page(struct page *page) * get_user_pages and page_mkclean and other calls that race to set up page * table entries. */ -#define GUP_PIN_COUNTING_BIAS (1U << 10) +#define GUP_PIN_COUNTING_BIAS (1U << 8) void unpin_user_page(struct page *page); void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages, If that fails to repro, then we would be zeroing in on the root cause. The branch is here (I just tested it and it seems healthy): g...@github.com:johnhubbard/linux.git pin_user_pages_tracking_v11_with_diags Hi, We tested the following branch and here comes results: Thanks for this testing run! [root@server consume_mtts]# (master) $ grep foll_pin /proc/vmstat nr_foll_pin_requested 0 nr_foll_pin_returned 0 Zero pinned pages! ...now I'm confused. Somehow FOLL_PIN and pin_user_pages*() calls are not happening. And although the backtraces below show some of my new routines (like try_grab_page), they also confirm the above: there is no pin_user_page*() call in the stack. In particular, it looks like ib_umem_get() is calling through to get_user_pages*(), rather than pin_user_pages*(). I don't see how this is possible, because the code on my screen shows ib_umem_get() calling pin_user_pages_fast(). Any thoughts or ideas are welcome here. However, glossing over all of that and assuming that the new GUP_PIN_COUNTING_BIAS of 256 is applied, it's interesting that we still see any overflow. I'm less confident now that this is a true refcount overflow. Also, any information that would get me closer to being able to attempt my own reproduction of the problem are *very* welcome. :) thanks, -- John Hubbard NVIDIA [root@serer consume_mtts]# (master) $ dmesg [ 425.221459] [ cut here ] [ 425.225894] WARNING: CPU: 1 PID: 6738 at mm/gup.c:61 try_grab_compound_head+0x90/0xa0 [ 425.228021] Modules linked in: mlx5_ib mlx5_core mlxfw mlx4_ib mlx4_en ptp pps_core mlx4_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre ip_tunnel rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core [last unloaded: mlxfw] [ 425.235266] CPU: 1 PID: 6738 Comm: consume_mtts Tainted: G O 5.5.0-rc2+ #1 [ 425.237480] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 425.239738] RIP: 0010:try_grab_compound_head+0x90/0xa0 [ 425.241170] Code: 06 48 8d 4f 34 f0 0f b1 57 34 74 cd 85 c0 74 cf 8d 14 06 f0 0f b1 11 74 c0 eb f1 8d 14 06 f0 0f b1 11 74 b5 85 c0 75 f3 eb b5 <0f> 0b 31 c0 c3 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 [ 425.245739] RSP: 0018:c96878a8 EFLAGS: 00010082 [ 425.247124] RAX: 8001 RBX: 7f780488a000 RCX: 0bb0 [ 425.248956] RDX: ea000e031087 RSI: 8a00 RDI: ea000dc58000 [ 425.250761] RBP: ea000e031080 R08: c9687974 R09: 000fffe0 [ 425.252661] R10: R11: 88836256 R12: 008a [ 425.254487] R13: 8003716000e7 R14: 7f780488a000 R15: c9687974 [ 425.256309] FS: 7f780d9d3740() GS:8883b1c8() knlGS: [ 425.258401] CS: 0010 DS: ES: CR0: 80050033 [ 425.259949] CR2: 02334048 CR3: 00039c68c001 CR4: 001606a0 [ 425.261884] Call Trace: [ 425.262735] gup_pgd_range+0x517/0x5a0 [ 425.263819] internal_get_user_pages_fast+0x210/0x250 [ 425.265193] ib_umem_get+0x298/0x550 [ib_uverbs] [ 425.266476] mr_umem_get+0xc9/0x260 [mlx5_ib] [ 425.267699] mlx5_ib_reg_user_mr+0xcc/0x7e0 [mlx5_ib] [ 425.269134] ?
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
Hi Sam, On Tue, Dec 24, 2019 at 12:31:11PM +0100, Sam Ravnborg wrote: > > Just a reminder of my 2 proposals: > > > > 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can > >split your enable/disable logic in 2 parts and make sure things are > >ready when the panel/next bridge tries to send DSI commands > > 2/ move everything that's needed to send DSI commands out of the > >->enable() path (maybe in runtime PM resume/suspend hooks) so you > >can call that in the DSI transfer path too > > > > As pointed out by Laurent, #1 doesn't work because some panel drivers > > send DSI commands in their ->prepare() hook, and ->pre_enable() methods > > are called in reverse order, meaning that the DRM panel bridge driver > > would try to issue DSI commands before the DSI host controllers is ready > > to send them. I still thing #2 is a good option. > > Jitao Shi suggested to extend panels so we had a sequence of: > > prepare_power() <= new callback, >here one should NOT be allowed to send >DSI commands > prepare() > enable() > ># ># panel is now ready to show your favourite christmas movie ># > > disable() > unprepare() > unprepare_power() <= new callback Please note that you will need corresponding bridge operations in order to implement the DRM panel bridge. > Would this help implement what you suggest above? > Relevant panels would then have to be updated - but this > is doable. The fundamental issue is that the enable/disable sequence requirements are inherently driven by sinks, while the bridge API goes from source to sink. A DSI panel could for instance require the following enable sequence. 0. DSI bus disabled (LP-00 state) 1. Power up the panel 2. Enable the DSI bus (LP-11 state) 3. Configure the panel (through DCS LP mode writes, SPI, GPIOs, ...) 4. Transition the source to HS mode, sending sync packets, but no data 5. Perform additional configuration for the panel 6. Enable transmission of video from the source For a given bus type there are thus well-specified states for a source (in this case disabled, enabled in LP mode, in HS mode, sending sync packets, sending video packets). As our API operates from source to sink, fine-grained control of bridges is difficult. We can of course always make bridge and panel operations more fine-grained, but that's more of a ad-hoc solution that may lead to abuse. We would at the very least document very explicitly what each operation would be allowed to do for every bus type. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/amd/display: use true,false for bool variable
On Tue, Dec 24, 2019 at 9:30 AM zhengbin wrote: > > zhengbin (8): > drm/amd/display: use true,false for bool variable in dc_link_ddc.c > drm/amd/display: use true,false for bool variable in > dcn10_hw_sequencer.c > drm/amd/display: use true,false for bool variable in dcn20_hwseq.c > drm/amd/display: use true,false for bool variable in > display_mode_vba_21.c > drm/amd/display: use true,false for bool variable in dce_calcs.c > drm/amd/display: use true,false for bool variable in > display_rq_dlg_calc_20.c > drm/amd/display: use true,false for bool variable in > display_rq_dlg_calc_20v2.c > drm/amd/display: use true,false for bool variable in > display_rq_dlg_calc_21.c > Applied. Thanks! Alex > drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 24 > +++--- > drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- > .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 4 ++-- > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 ++-- > .../display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 24 > +++--- > .../dc/dml/dcn20/display_rq_dlg_calc_20v2.c| 24 > +++--- > .../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 6 +++--- > .../display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 24 > +++--- > 8 files changed, 56 insertions(+), 56 deletions(-) > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: use true, false for bool variable in vega20_hwmgr.c
On Tue, Dec 24, 2019 at 9:30 AM zhengbin wrote: > > Fixes coccicheck warning: > > drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:875:1-31: WARNING: > Assignment of 0/1 to bool variable > > Reported-by: Hulk Robot > Signed-off-by: zhengbin Applied. thanks! Alex > --- > drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c > index 5bcf0d6..3b3ec56 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c > @@ -872,7 +872,7 @@ static int vega20_override_pcie_parameters(struct > pp_hwmgr *hwmgr) > "[OverridePcieParameters] Attempt to override pcie params > failed!", > return ret); > > - data->pcie_parameters_override = 1; > + data->pcie_parameters_override = true; > data->pcie_gen_level1 = pcie_gen; > data->pcie_width_level1 = pcie_width; > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] phy: Add DisplayPort configuration options
+ Maxime (Fixed Maxime's email address)
On 23/12/19 5:57 PM, Kishon Vijay Abraham I wrote:
> + Maxime
>
> Hi,
>
> On 23/12/19 12:24 PM, Yuti Amonkar wrote:
>> Allow DisplayPort PHYs to be configured through the generic
>> functions through a custom structure added to the generic union.
>> The configuration structure is used for reconfiguration of
>> DisplayPort PHYs during link training operation.
>>
>> The parameters added here are the ones defined in the DisplayPort
>> spec which include link rate, number of lanes, voltage swing
>> and pre-emphasis.
>
> Which version of display port specification?
>
> Rest of commit log should move below the "---"
>
>
>>
>> This patch was a part of [1] series earlier but we think that it needs
>> to have a separate attention of the reviewers. Also as both [1] & [2] are
>> dependent on this patch, our sincere request to reviewers to have a
>> faster review of this patch.
>>
>> [1]
>>
>> https://lkml.org/lkml/2019/12/11/455
>>
>> [2]
>>
>> https://patchwork.kernel.org/cover/11271191/
>
> Thanks
> Kishon
>
>>
>> Signed-off-by: Yuti Amonkar
>> ---
>> include/linux/phy/phy-dp.h | 95
>> ++
>> include/linux/phy/phy.h | 4 ++
>> 2 files changed, 99 insertions(+)
>> create mode 100644 include/linux/phy/phy-dp.h
>>
>> diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
>> new file mode 100644
>> index 000..18cad23
>> --- /dev/null
>> +++ b/include/linux/phy/phy-dp.h
>> @@ -0,0 +1,95 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (C) 2019 Cadence Design Systems Inc.
>> + */
>> +
>> +#ifndef __PHY_DP_H_
>> +#define __PHY_DP_H_
>> +
>> +#include
>> +
>> +/**
>> + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
>> + *
>> + * This structure is used to represent the configuration state of a
>> + * DisplayPort phy.
>> + */
>> +struct phy_configure_opts_dp {
>> + /**
>> + * @link_rate:
>> + *
>> + * Link Rate, in Mb/s, of the main link.
>> + *
>> + * Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100
>> Mb/s
>> + */
>> + unsigned int link_rate;
>> +
>> + /**
>> + * @lanes:
>> + *
>> + * Number of active, consecutive, data lanes, starting from
>> + * lane 0, used for the transmissions on main link.
>> + *
>> + * Allowed values: 1, 2, 4
>> + */
>> + unsigned int lanes;
>> +
>> + /**
>> + * @voltage:
>> + *
>> + * Voltage swing levels, as specified by DisplayPort specification,
>> + * to be used by particular lanes. One value per lane.
>> + * voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
>> + *
>> + * Maximum value: 3
>> + */
>> + unsigned int voltage[4];
>> +
>> + /**
>> + * @pre:
>> + *
>> + * Pre-emphasis levels, as specified by DisplayPort
>> specification, to be
>> + * used by particular lanes. One value per lane.
>> + *
>> + * Maximum value: 3
>> + */
>> + unsigned int pre[4];
>> +
>> + /**
>> + * @ssc:
>> + *
>> + * Flag indicating, whether or not to enable spread-spectrum
>> clocking.
>> + *
>> + */
>> + u8 ssc : 1;
>> +
>> + /**
>> + * @set_rate:
>> + *
>> + * Flag indicating, whether or not reconfigure link rate and SSC to
>> + * requested values.
>> + *
>> + */
>> + u8 set_rate : 1;
>> +
>> + /**
>> + * @set_lanes:
>> + *
>> + * Flag indicating, whether or not reconfigure lane count to
>> + * requested value.
>> + *
>> + */
>> + u8 set_lanes : 1;
>> +
>> + /**
>> + * @set_voltages:
>> + *
>> + * Flag indicating, whether or not reconfigure voltage swing
>> + * and pre-emphasis to requested values. Only lanes specified
>> + * by "lanes" parameter will be affected.
>> + *
>> + */
>> + u8 set_voltages : 1;
>> +};
>> +
>> +#endif /* __PHY_DP_H_ */
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index 15032f14..ba0aab5 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -16,6 +16,7 @@
>> #include
>> #include
>> +#include
>> #include
>> struct phy;
>> @@ -46,9 +47,12 @@ enum phy_mode {
>> *
>> * @mipi_dphy: Configuration set applicable for phys supporting
>> * the MIPI_DPHY phy mode.
>> + * @dp: Configuration set applicable for phys supporting
>> + * the DisplayPort protocol.
>> */
>> union phy_configure_opts {
>> struct phy_configure_opts_mipi_dphy mipi_dphy;
>> + struct phy_configure_opts_dp dp;
>> };
>> /**
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] phy: Add DisplayPort configuration options
+ Maxime
Hi,
On 23/12/19 12:24 PM, Yuti Amonkar wrote:
Allow DisplayPort PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The configuration structure is used for reconfiguration of
DisplayPort PHYs during link training operation.
The parameters added here are the ones defined in the DisplayPort
spec which include link rate, number of lanes, voltage swing
and pre-emphasis.
Which version of display port specification?
Rest of commit log should move below the "---"
This patch was a part of [1] series earlier but we think that it needs
to have a separate attention of the reviewers. Also as both [1] & [2] are
dependent on this patch, our sincere request to reviewers to have a
faster review of this patch.
[1]
https://lkml.org/lkml/2019/12/11/455
[2]
https://patchwork.kernel.org/cover/11271191/
Thanks
Kishon
Signed-off-by: Yuti Amonkar
---
include/linux/phy/phy-dp.h | 95 ++
include/linux/phy/phy.h| 4 ++
2 files changed, 99 insertions(+)
create mode 100644 include/linux/phy/phy-dp.h
diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
new file mode 100644
index 000..18cad23
--- /dev/null
+++ b/include/linux/phy/phy-dp.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Cadence Design Systems Inc.
+ */
+
+#ifndef __PHY_DP_H_
+#define __PHY_DP_H_
+
+#include
+
+/**
+ * struct phy_configure_opts_dp - DisplayPort PHY configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * DisplayPort phy.
+ */
+struct phy_configure_opts_dp {
+ /**
+* @link_rate:
+*
+* Link Rate, in Mb/s, of the main link.
+*
+* Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100 Mb/s
+*/
+ unsigned int link_rate;
+
+ /**
+* @lanes:
+*
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions on main link.
+*
+* Allowed values: 1, 2, 4
+*/
+ unsigned int lanes;
+
+ /**
+* @voltage:
+*
+* Voltage swing levels, as specified by DisplayPort specification,
+* to be used by particular lanes. One value per lane.
+* voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
+*
+* Maximum value: 3
+*/
+ unsigned int voltage[4];
+
+ /**
+* @pre:
+*
+* Pre-emphasis levels, as specified by DisplayPort specification, to be
+* used by particular lanes. One value per lane.
+*
+* Maximum value: 3
+*/
+ unsigned int pre[4];
+
+ /**
+* @ssc:
+*
+* Flag indicating, whether or not to enable spread-spectrum clocking.
+*
+*/
+ u8 ssc : 1;
+
+ /**
+* @set_rate:
+*
+* Flag indicating, whether or not reconfigure link rate and SSC to
+* requested values.
+*
+*/
+ u8 set_rate : 1;
+
+ /**
+* @set_lanes:
+*
+* Flag indicating, whether or not reconfigure lane count to
+* requested value.
+*
+*/
+ u8 set_lanes : 1;
+
+ /**
+* @set_voltages:
+*
+* Flag indicating, whether or not reconfigure voltage swing
+* and pre-emphasis to requested values. Only lanes specified
+* by "lanes" parameter will be affected.
+*
+*/
+ u8 set_voltages : 1;
+};
+
+#endif /* __PHY_DP_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 15032f14..ba0aab5 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
struct phy;
@@ -46,9 +47,12 @@ enum phy_mode {
*
* @mipi_dphy:Configuration set applicable for phys supporting
*the MIPI_DPHY phy mode.
+ * @dp:Configuration set applicable for phys supporting
+ * the DisplayPort protocol.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
+ struct phy_configure_opts_dpdp;
};
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] phy: Add DisplayPort configuration options
Hi,
Please note that I don't have access to the displayPort spec, so I'll
only comment on the content of that patch, not whether it's complete
or not.
On Mon, Dec 23, 2019 at 02:41:13PM +0100, Yuti Amonkar wrote:
> Allow DisplayPort PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
> The configuration structure is used for reconfiguration of
> DisplayPort PHYs during link training operation.
>
> The parameters added here are the ones defined in the DisplayPort
> spec 1.4 which include link rate, number of lanes, voltage swing
> and pre-emphasis.
>
> Signed-off-by: Yuti Amonkar
> ---
>
> This patch was a part of [1] series earlier but we think that it needs
> to have a separate attention of the reviewers. Also as both [1] & [2] are
> dependent on this patch, our sincere request to reviewers to have a
> faster review of this patch.
>
> [1]
>
> https://lkml.org/lkml/2019/12/11/455
>
> [2]
>
> https://patchwork.kernel.org/cover/11271191/
>
> include/linux/phy/phy-dp.h | 95
> ++
> include/linux/phy/phy.h| 4 ++
> 2 files changed, 99 insertions(+)
> create mode 100644 include/linux/phy/phy-dp.h
>
> diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
> new file mode 100644
> index 000..18cad23
> --- /dev/null
> +++ b/include/linux/phy/phy-dp.h
> @@ -0,0 +1,95 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 Cadence Design Systems Inc.
> + */
> +
> +#ifndef __PHY_DP_H_
> +#define __PHY_DP_H_
> +
> +#include
> +
> +/**
> + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * DisplayPort phy.
> + */
> +struct phy_configure_opts_dp {
> + /**
> + * @link_rate:
> + *
> + * Link Rate, in Mb/s, of the main link.
> + *
> + * Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100 Mb/s
> + */
> + unsigned int link_rate;
> +
> + /**
> + * @lanes:
> + *
> + * Number of active, consecutive, data lanes, starting from
> + * lane 0, used for the transmissions on main link.
> + *
> + * Allowed values: 1, 2, 4
> + */
> + unsigned int lanes;
> +
> + /**
> + * @voltage:
> + *
> + * Voltage swing levels, as specified by DisplayPort specification,
> + * to be used by particular lanes. One value per lane.
> + * voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
> + *
> + * Maximum value: 3
> + */
> + unsigned int voltage[4];
> +
> + /**
> + * @pre:
> + *
> + * Pre-emphasis levels, as specified by DisplayPort specification, to be
> + * used by particular lanes. One value per lane.
> + *
> + * Maximum value: 3
> + */
> + unsigned int pre[4];
> +
> + /**
> + * @ssc:
> + *
> + * Flag indicating, whether or not to enable spread-spectrum clocking.
> + *
> + */
> + u8 ssc : 1;
> +
> + /**
> + * @set_rate:
> + *
> + * Flag indicating, whether or not reconfigure link rate and SSC to
> + * requested values.
> + *
> + */
> + u8 set_rate : 1;
> +
> + /**
> + * @set_lanes:
> + *
> + * Flag indicating, whether or not reconfigure lane count to
> + * requested value.
> + *
> + */
> + u8 set_lanes : 1;
> +
> + /**
> + * @set_voltages:
> + *
> + * Flag indicating, whether or not reconfigure voltage swing
> + * and pre-emphasis to requested values. Only lanes specified
> + * by "lanes" parameter will be affected.
> + *
> + */
> + u8 set_voltages : 1;
I'm not quite sure what these flags are supposed to be doing, or what
use-cases they cover. The current API is using validate to make sure
that we can have a handshake between the caller and its PHY and must
never apply the configuration, and configure must always apply the
configuration. These flags look redundant.
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Jitao Shi This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi Reviewed-by: Daniel Kurtz [uli: followed API changes, removed FW update feature] Signed-off-by: Ulrich Hecht Signed-off-by: Enric Balletbo i Serra Tested-by: Hsin-Yi Wang --- One of the reviews from Laurent was to use 'i2c_new_ancillary_device'. I didn't change this for two reasons. 1) It doesn't have a devm version, so the remove path is more simple using the devm_i2c_new_dummy_device family. 2) IIUC the ancillary function is useful when you want to retrieve the address from the firmware or DT, that's not really the case here, as we have a base address and fixed offset to the base address which I think is not configurable. Let me know if you still think that I should use the ancillary call. Changes in v23: - Merge mute/unmute functions into one (Nicolas Boichat) - Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia) - Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat and Enric) - Add space between address and address parameter 'address%02x' (Nicolas Boichat) - Add Tested-by Hsin-Yi - Added me as author after the refactor Changes in v22: - Remove sysfs attributes because are not really used (Enric Balletbo) - Use enum for address page offsets (Ezequiel Garcia) - Remove enable tracking (Enric Balletbo) - Use panel_bridge API (Laurent Pinchart) - Do not use kernel-doc format for non kernel-doc formatted commands (Enric Balletbo) - Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia) - Use time_is_after_jiffies idiom (Ezequiel Garcia) - Remove unused macros (Ezequiel Garcia) - Fix weird alignment in dsi->mode_flags (Laurent Pinchart) - Use drm_of_find_panel_or_bridge helper (Laurent Pinchart) - Remove mode-sel-gpios as is not used (Laurent Pinchart) - Remove error messages to get gpios as the core will already report it (Enric Balletbo) - Remove redundant message getting the regulators (Laurent Pinchart) - Rename sleep-gpios to powerdown-gpios (Laurent Pinchart) - Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent Pinchart) - Fix race with userspace accessing the sysfs attributes (Laurent Pinchart) - Remove id_table as is only used on DR platforms (Laurent Pinchart) - Convert to new i2c device probe() (Laurent Pinchart) - Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart) - Remove unnused global variables (Laurent Pinchart) - Remove unnused fields in ps8640 struct (Laurent Pinchart) - Remove commented-out headers (Laurent Pinchart) Changes in v21: - Use devm_i2c_new_dummy_device and fix build issue using deprecated i2c_new_dummy - Fix build issue due missing drm_bridge.h - Do not remove in ps8640_remove device managed resources Changes in v19: - fixed return value of ps8640_probe() when no panel is found Changes in v18: - followed DRM API changes - use DEVICE_ATTR_RO() - remove firmware update code - add SPDX identifier Changes in v17: - remove some unused head files. - add macros for ps8640 pages. - remove ddc_i2c client - add mipi_dsi_device_register_full - remove the manufacturer from the name and i2c_device_id Changes in v16: - Disable ps8640 DSI MCS Function. - Rename gpios name more clearly. - Tune the ps8640 power on sequence. Changes in v15: - Drop drm_connector_(un)register calls from parade ps8640. The main DRM driver mtk_drm_drv now calls drm_connector_register_all() after drm_dev_register() in the mtk_drm_bind() function. That function should iterate over all connectors and call drm_connector_register() for each of them. So, remove drm_connector_(un)register calls from parade ps8640. Changes in v14: - update copyright info. - change bridge_to_ps8640 and connector_to_ps8640 to inline function. - fix some coding style. - use sizeof as array counter. - use drm_get_edid when read edid. - add mutex when firmware updating. Changes in v13: - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len) - fix PAGE2_SW_REST tyro. - move the buf[3] init to entrance of the function. Changes in v12: - fix hw_chip_id build warning Changes in v11: - Remove depends on I2C, add DRM depends - Reuse ps8640_write_bytes() in ps8640_write_byte() - Use timer check for polling like the routines in - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail - Check the ps8640 hardware id in ps8640_validate_firmware - Remove fw_version check - Move ps8640_validate_firmware before ps8640_enter_bl - Add ddc_i2c unregister when probe fail and ps8640_remove drivers/gpu/drm/bridge/Kconfig | 11 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/parade-ps8640.c | 348 + 3 files changed, 360 insertions(+) create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c diff --git a/drivers/gpu/drm/bridge/Kconfig
[PATCH v3 1/3] dt-bindings: Add vendor prefix for Satoz
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Signed-off-by: Miquel Raynal Acked-by: Rob Herring --- Changes since v2: * None. Changes since v1: * Added Rob's Ack. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..4894c5314b49 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -819,6 +819,8 @@ patternProperties: description: Sancloud Ltd "^sandisk,.*": description: Sandisk Corporation + "^satoz,.*": +description: Satoz International Co., Ltd "^sbs,.*": description: Smart Battery System "^schindler,.*": -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/amdgpu: use true, false for bool variable in mxgpu_nv.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:255:2-20: WARNING: Assignment of 0/1 to
bool variable
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:267:2-20: WARNING: Assignment of 0/1 to
bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
index 1c3a7d4..237fa5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
@@ -252,7 +252,7 @@ static void xgpu_nv_mailbox_flr_work(struct work_struct
*work)
*/
locked = mutex_trylock(>lock_reset);
if (locked)
- adev->in_gpu_reset = 1;
+ adev->in_gpu_reset = true;
do {
if (xgpu_nv_mailbox_peek_msg(adev) == IDH_FLR_NOTIFICATION_CMPL)
@@ -264,7 +264,7 @@ static void xgpu_nv_mailbox_flr_work(struct work_struct
*work)
flr_done:
if (locked) {
- adev->in_gpu_reset = 0;
+ adev->in_gpu_reset = false;
mutex_unlock(>lock_reset);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: Add vendor prefix for Satoz
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Signed-off-by: Miquel Raynal Acked-by: Rob Herring --- Changes since v1: * Added Rob's Ack. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 967e78c5ec0a..4894c5314b49 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -819,6 +819,8 @@ patternProperties: description: Sancloud Ltd "^sandisk,.*": description: Sandisk Corporation + "^satoz,.*": +description: Satoz International Co., Ltd "^sbs,.*": description: Smart Battery System "^schindler,.*": -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Laurent, On 23/12/19 15:35, Enric Balletbo i Serra wrote: > From: Jitao Shi > > This patch adds drm_bridge driver for parade DSI to eDP bridge chip. > > Signed-off-by: Jitao Shi > Reviewed-by: Daniel Kurtz > [uli: followed API changes, removed FW update feature] > Signed-off-by: Ulrich Hecht > Signed-off-by: Enric Balletbo i Serra > Tested-by: Hsin-Yi Wang > --- > One of the reviews from Laurent was to use 'i2c_new_ancillary_device'. I > didn't change this for two reasons. > 1) It doesn't have a devm version, so the remove path is more simple > using the devm_i2c_new_dummy_device family. > 2) IIUC the ancillary function is useful when you want to retrieve the > address from the firmware or DT, that's not really the case here, as we > have a base address and fixed offset to the base address which I think > is not configurable. > > Let me know if you still think that I should use the ancillary call. > > Changes in v23: > - Merge mute/unmute functions into one (Nicolas Boichat) > - Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia) > - Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat > and Enric) > - Add space between address and address parameter 'address%02x' (Nicolas > Boichat) > - Add Tested-by Hsin-Yi > - Added me as author after the refactor > > Changes in v22: > - Remove sysfs attributes because are not really used (Enric Balletbo) > - Use enum for address page offsets (Ezequiel Garcia) > - Remove enable tracking (Enric Balletbo) > - Use panel_bridge API (Laurent Pinchart) > - Do not use kernel-doc format for non kernel-doc formatted commands (Enric > Balletbo) > - Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia) > - Use time_is_after_jiffies idiom (Ezequiel Garcia) > - Remove unused macros (Ezequiel Garcia) > - Fix weird alignment in dsi->mode_flags (Laurent Pinchart) > - Use drm_of_find_panel_or_bridge helper (Laurent Pinchart) > - Remove mode-sel-gpios as is not used (Laurent Pinchart) > - Remove error messages to get gpios as the core will already report it > (Enric Balletbo) > - Remove redundant message getting the regulators (Laurent Pinchart) > - Rename sleep-gpios to powerdown-gpios (Laurent Pinchart) > - Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent > Pinchart) > - Fix race with userspace accessing the sysfs attributes (Laurent Pinchart) > - Remove id_table as is only used on DR platforms (Laurent Pinchart) > - Convert to new i2c device probe() (Laurent Pinchart) > - Use i2c_smbus_read/write helpers instead of open coding it (Laurent > Pinchart) > - Remove unnused global variables (Laurent Pinchart) > - Remove unnused fields in ps8640 struct (Laurent Pinchart) > - Remove commented-out headers (Laurent Pinchart) > > Changes in v21: > - Use devm_i2c_new_dummy_device and fix build issue using deprecated > i2c_new_dummy > - Fix build issue due missing drm_bridge.h > - Do not remove in ps8640_remove device managed resources > > Changes in v19: > - fixed return value of ps8640_probe() when no panel is found > > Changes in v18: > - followed DRM API changes > - use DEVICE_ATTR_RO() > - remove firmware update code > - add SPDX identifier > > Changes in v17: > - remove some unused head files. > - add macros for ps8640 pages. > - remove ddc_i2c client > - add mipi_dsi_device_register_full > - remove the manufacturer from the name and i2c_device_id > > Changes in v16: > - Disable ps8640 DSI MCS Function. > - Rename gpios name more clearly. > - Tune the ps8640 power on sequence. > > Changes in v15: > - Drop drm_connector_(un)register calls from parade ps8640. >The main DRM driver mtk_drm_drv now calls >drm_connector_register_all() after drm_dev_register() in the >mtk_drm_bind() function. That function should iterate over all >connectors and call drm_connector_register() for each of them. >So, remove drm_connector_(un)register calls from parade ps8640. > > Changes in v14: > - update copyright info. > - change bridge_to_ps8640 and connector_to_ps8640 to inline function. > - fix some coding style. > - use sizeof as array counter. > - use drm_get_edid when read edid. > - add mutex when firmware updating. > > Changes in v13: > - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 > *data, u16 data_len) > - fix PAGE2_SW_REST tyro. > - move the buf[3] init to entrance of the function. > > Changes in v12: > - fix hw_chip_id build warning > > Changes in v11: > - Remove depends on I2C, add DRM depends > - Reuse ps8640_write_bytes() in ps8640_write_byte() > - Use timer check for polling like the routines in > - Fix no drm_connector_unregister/drm_connector_cleanup when > ps8640_bridge_attach fail > - Check the ps8640 hardware id in ps8640_validate_firmware > - Remove fw_version check > - Move ps8640_validate_firmware before ps8640_enter_bl > - Add ddc_i2c unregister when probe fail and ps8640_remove > >
[PATCH 2/8] drm/amd/display: use true, false for bool variable in dcn10_hw_sequencer.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:482:6-14: WARNING:
Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:485:2-10: WARNING:
Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 9c55e48..2baff3c 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -479,10 +479,10 @@ void dcn10_enable_power_gating_plane(
struct dce_hwseq *hws,
bool enable)
{
- bool force_on = 1; /* disable power gating */
+ bool force_on = true; /* disable power gating */
if (enable)
- force_on = 0;
+ force_on = false;
/* DCHUBP0/1/2/3 */
REG_UPDATE(DOMAIN0_PG_CONFIG, DOMAIN0_POWER_FORCEON, force_on);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lima] [RFC v1 0/1] drm: lima: devfreq and cooling device support
于 2019年12月24日 GMT+08:00 下午7:28:41, Martin Blumenstingl 写到: >Hi Alyssa, > >On Mon, Dec 16, 2019 at 4:48 PM Alyssa Rosenzweig > wrote: >> >> If so much code is being duplicated over, I'm wondering if it makes >> sense for us to move some of the common devfreq code to core DRM >> helpers? >if you have any recommendation where to put it then please let me know >(I am not familiar with the DRM subsystem at all) > >my initial idea was that the devfreq logic needs the same information >that the scheduler needs (whether we're submitting something to be >executed, there was a timeout, ...). >however, looking at drivers/gpu/drm/scheduler/ this seems pretty >stand-alone so I'm not sure it should go there >also the Mali-4x0 GPUs have some "PMU" which *may* be used instead of It's optional. We cannot promise its existance on a given hardware, and I heard that at least on Allwinner H5 Mali PMU is broken. >polling the statistics internally >so this is where I realize that with my current knowledge I don't know >enough about lima, panfrost, DRM or the devfreq subsystem to get a >good idea where to put the code. > > >Martin >___ >lima mailing list >l...@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/lima -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915: use true, false for bool variable in intel_crt.c
Fixes coccicheck warning:
drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1
to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1
to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1
to bool variable
Reported-by: Hulk Robot
Signed-off-by: Ma Feng
---
drivers/gpu/drm/i915/display/intel_crt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index b2b1336..8596eef 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -440,7 +440,7 @@ static bool intel_ironlake_crt_detect_hotplug(struct
drm_connector *connector)
bool turn_off_dac = HAS_PCH_SPLIT(dev_priv);
u32 save_adpa;
- crt->force_hotplug_required = 0;
+ crt->force_hotplug_required = false;
save_adpa = adpa = I915_READ(crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n",
adpa);
@@ -925,7 +925,7 @@ void intel_crt_reset(struct drm_encoder *encoder)
POSTING_READ(crt->adpa_reg);
DRM_DEBUG_KMS("crt adpa set to 0x%x\n", adpa);
- crt->force_hotplug_required = 1;
+ crt->force_hotplug_required = true;
}
}
@@ -1063,7 +1063,7 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
/*
* Configure the automatic hotplug detection stuff
*/
- crt->force_hotplug_required = 0;
+ crt->force_hotplug_required = false;
/*
* TODO: find a proper way to discover whether we need to set the the
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support
Add support for the Satoz SAT050AT40H12R2 RGB panel.
Signed-off-by: Miquel Raynal
---
Changes since v2:
* Dropped two uneeded lines which would fail the build.
Changes since v1:
* Switched to display_timing's instead of display_mode.
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ac6f6b5d200d..cc1595c5633a 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2559,6 +2559,29 @@ static const struct panel_desc samsung_ltn140at29_301 = {
},
};
+static const struct display_timing satoz_sat050at40h12r2_timing = {
+ .pixelclock = { 3330, 3330, 5000 },
+ .hactive = {800, 800, 800},
+ .hfront_porch = {16, 210, 354},
+ .hback_porch = {46, 46, 46},
+ .hsync_len = {1, 1, 40},
+ .vactive = {480, 480, 480},
+ .vfront_porch = {7, 22, 147},
+ .vback_porch = {23, 23, 23},
+ .vsync_len = {1, 1, 20},
+};
+
+static const struct panel_desc satoz_sat050at40h12r2 = {
+ .timings = _sat050at40h12r2_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 108,
+ .height = 65,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
.clock = 168480,
.hdisplay = 1920,
@@ -3354,6 +3377,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "samsung,ltn140at29-301",
.data = _ltn140at29_301,
+ }, {
+ .compatible = "satoz,sat050at40h12r2",
+ .data = _sat050at40h12r2,
}, {
.compatible = "sharp,ld-d5116z01b",
.data = _ld_d5116z01b,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panel: simple: Support reset GPIOs
The panel common bindings provide a gpios-reset property. Let's
support it in the simple driver.
Two fields are added to the panel description structure: the time to
assert the reset and the time to wait right after before starting to
interact with it in any manner. In case these default values are not
filled but the GPIO is present in the DT, default values are applied.
Signed-off-by: Miquel Raynal
---
Changes since v1:
* Add two parameters in the panel description structure.
* Ensure the reset is asserted the right amount of time and the
deasserted before continuing if a reset GPIO is given.
drivers/gpu/drm/panel/panel-simple.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..ac6f6b5d200d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -38,6 +38,9 @@
#include
#include
+#define MIN_DEFAULT_RESET_US 10
+#define MIN_DEFAULT_WAIT_US 10
+
/**
* @modes: Pointer to array of fixed modes appropriate for this panel. If
* only one mode then this can just be the address of this the mode.
@@ -94,6 +97,10 @@ struct panel_desc {
u32 bus_format;
u32 bus_flags;
+
+ /* Minimum reset duration and wait period after it in us */
+ u32 reset_time;
+ u32 reset_wait;
};
struct panel_simple {
@@ -109,6 +116,7 @@ struct panel_simple {
struct i2c_adapter *ddc;
struct gpio_desc *enable_gpio;
+ struct gpio_desc *reset_gpio;
struct drm_display_mode override_mode;
};
@@ -432,12 +440,34 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
if (IS_ERR(panel->supply))
return PTR_ERR(panel->supply);
+ panel->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(panel->reset_gpio)) {
+ err = PTR_ERR(panel->reset_gpio);
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "failed to request reset pin: %d\n", err);
+ return err;
+ } else if (panel->reset_gpio) {
+ u32 reset_time = panel->desc->reset_time;
+ u32 reset_wait = panel->desc->reset_wait;
+
+ if (!reset_time)
+ reset_time = MIN_DEFAULT_RESET_US;
+
+ if (!reset_wait)
+ reset_wait = MIN_DEFAULT_WAIT_US;
+
+ usleep_range(reset_time, 2 * reset_time);
+ gpiod_set_value_cansleep(panel->reset_gpio, 0);
+ usleep_range(reset_wait, 2 * reset_wait);
+ }
+
panel->enable_gpio = devm_gpiod_get_optional(dev, "enable",
GPIOD_OUT_LOW);
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
if (err != -EPROBE_DEFER)
- dev_err(dev, "failed to request GPIO: %d\n", err);
+ dev_err(dev, "failed to request enable pin: %d\n", err);
return err;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings in yaml format
On Mon, Dec 23, 2019 at 04:16:40PM +0100, Yuti Amonkar wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml | 109
> +
> 1 file changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index 000..aed6224
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,109 @@
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> + - Swapnil Jakhade
> + - Yuti Amonkar
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp8546
> + - ti,j721e-mhdp8546
> +
> + clocks:
> +maxItems: 1
> +description:
> + DP bridge clock, it's used by the IP to know how to translate a number
> of
> + clock cycles into a time (which is used to comply with DP standard
> timings
> + and delays).
> +
> + reg:
> +minItems: 1
> +maxItems: 2
> +items:
> + - description:
> + Register block of mhdptx apb registers upto PHY mapped
> area(AUX_CONFIG_P).
> + The AUX and PMA registers are mapped to associated phy driver.
> + - description:
> + Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> +
> + reg-names:
> +minItems: 1
> +maxItems: 2
> +items:
> + - const: mhdptx
> + - const: j721e-intg
You should have an if / then clause to validate that the length is the
proper one based on the value of the compatible.
> + phys:
> +description: see the
> Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
phys is a generic property, so we shouldn't tie it to one particular
phy. Especially since there's nothing in it that really explain what
this property is supposed to be.
> + phy-names:
> +const: dpphy
> +
> + ports:
> +type: object
> +description:
> + Ports as described in Documentation/devicetree/bindings/graph.txt
> +properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> + port@0:
> + description:
> + input port representing the DP bridge input
> +
> + port@1:
> + description:
> + output port representing the DP bridge output
> +required:
> + - port@0
> + - port@1
> + - '#address-cells'
> + - '#size-cells'
> +
> +required:
> + - compatible
> + - clocks
> + - reg
> + - phys
> + - phy-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0xf0 0xfc00 0x0 0x200>;
There's two items here, yet you're not using the TI compatible?
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/amd/display: use true, false for bool variable in dce_calcs.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:157:46-64: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:159:2-20: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:161:46-64: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:163:2-20: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:289:1-12: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:290:1-12: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:341:3-14: WARNING: Assignment
of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:343:4-15: WARNING: Assignment
of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index a1d4925..5d081c4 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -154,14 +154,14 @@ static void calculate_bandwidth(
- if (data->d0_underlay_mode == bw_def_none) { d0_underlay_enable = 0; }
- else {
- d0_underlay_enable = 1;
- }
- if (data->d1_underlay_mode == bw_def_none) { d1_underlay_enable = 0; }
- else {
- d1_underlay_enable = 1;
- }
+ if (data->d0_underlay_mode == bw_def_none)
+ d0_underlay_enable = false;
+ else
+ d0_underlay_enable = true;
+ if (data->d1_underlay_mode == bw_def_none)
+ d1_underlay_enable = false;
+ else
+ d1_underlay_enable = true;
data->number_of_underlay_surfaces = d0_underlay_enable +
d1_underlay_enable;
switch (data->underlay_surface_type) {
case bw_def_420:
@@ -286,8 +286,8 @@ static void calculate_bandwidth(
data->cursor_width_pixels[2] = bw_int_to_fixed(0);
data->cursor_width_pixels[3] = bw_int_to_fixed(0);
/* graphics surface parameters from spreadsheet*/
- fbc_enabled = 0;
- lpt_enabled = 0;
+ fbc_enabled = false;
+ lpt_enabled = false;
for (i = 4; i <= maximum_number_of_surfaces - 3; i++) {
if (i < data->number_of_displays + 4) {
if (i == 4 && data->d0_underlay_mode ==
bw_def_underlay_only) {
@@ -338,9 +338,9 @@ static void calculate_bandwidth(
data->access_one_channel_only[i] = 0;
}
if (data->fbc_en[i] == 1) {
- fbc_enabled = 1;
+ fbc_enabled = true;
if (data->lpt_en[i] == 1) {
- lpt_enabled = 1;
+ lpt_enabled = true;
}
}
data->cursor_width_pixels[i] =
bw_int_to_fixed(vbios->cursor_width);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/amd/display: use true, false for bool variable in dc_link_ddc.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:593:6-9: WARNING: Assignment
of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index c2c136b..a49c10d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -590,7 +590,7 @@ bool dal_ddc_submit_aux_command(struct ddc_service *ddc,
struct aux_payload *payload)
{
uint32_t retrieved = 0;
- bool ret = 0;
+ bool ret = false;
if (!ddc)
return false;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support
Hello,
Miquel Raynal wrote on Tue, 24 Dec 2019
15:05:51 +0100:
> Add support for the Satoz SAT050AT40H12R2 RGB panel.
>
> Signed-off-by: Miquel Raynal
> ---
>
> Changes since v1:
> * Switched to display_timing's instead of display_mode.
>
> drivers/gpu/drm/panel/panel-simple.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index ac6f6b5d200d..00538553a188 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2559,6 +2559,31 @@ static const struct panel_desc samsung_ltn140at29_301
> = {
> },
> };
>
> +static const struct display_timing satoz_sat050at40h12r2_timing = {
> + .pixelclock = { 3330, 3330, 5000 },
> + .hactive = {800, 800, 800},
> + .hfront_porch = {16, 210, 354},
> + .hback_porch = {46, 46, 46},
> + .hsync_len = {1, 1, 40},
> + .vactive = {480, 480, 480},
> + .vfront_porch = {7, 22, 147},
> + .vback_porch = {23, 23, 23},
> + .vsync_len = {1, 1, 20},
> +};
> +
> +static const struct panel_desc satoz_sat050at40h12r2 = {
> + .timings = _sat050at40h12r2_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 108,
> + .height = 65,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .reset_time = 10,
> + .reset_wait = 1,
I dit not generate the patch from the right branch: this is a proposal
for the reset GPIO change and should not appear here. Please forget
about this series, I will respin a v3 without these two lines.
Sorry for the noise.
Thanks,
Miquèl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Nicolas,
On 23/12/19 10:14, Nicolas Boichat wrote:
> On Mon, Dec 23, 2019 at 3:10 PM Enric Balletbo i Serra
> wrote:
>>
>> Hi Nicolas,
>>
>> Many thanks for you review. Just preparing a new version with your comments
>> addressed.
>>
>> On 20/12/19 9:44, Nicolas Boichat wrote:
>>> On Fri, Dec 20, 2019 at 4:17 PM Enric Balletbo i Serra
>>> wrote:
From: Jitao Shi
This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
Signed-off-by: Jitao Shi
Reviewed-by: Daniel Kurtz
Reviewed-by: Enric Balletbo i Serra
[uli: followed API changes, removed FW update feature]
Signed-off-by: Ulrich Hecht
Signed-off-by: Enric Balletbo i Serra
---
>> [snip]
+ ret = i2c_smbus_write_byte_data(client, PAGE2_MCS_EN,
+ status & ~MCS_EN);
+ if (ret < 0) {
+ DRM_ERROR("failed write PAGE2_MCS_EN: %d\n", ret);
+ goto err_regulators_disable;
+ }
+
+ ret = ps8640_bridge_unmute(ps_bridge);
+ if (ret)
+ DRM_ERROR("failed to enable unmutevideo: %d\n", ret);
>>>
>>> failed to unmute? Or failed to enable?
>>>
>>
>> failed to unmute sound more clear to me.
>
> I may be wrong, but I have the feeling that the functions
> "mute/unmute" video/display, actually... And that the function naming
> is strange...
>
Yes, that's strange.
> You could just try to remove the calls, as there is no audio on the
> board you have (elm), so if video still works, maybe this is actually
> audio ,-)
>
And without those the display doesn't work. So I suspect that what is wrong and
confusing is the message, instead of mute/unmute, and based on the register
names this looks more like an internal regulator that you need to enable and
disable, so I'll change the error message accordingly.
Thanks,
Enric
> Thanks,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1] drm/msm: update LANE_CTRL register value from default value
Updating REG_DSI_LANE_CTRL register value by reading default
register value and writing it back using bitwise OR with
DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST. This works for all panels.
Signed-off-by: Harigovindan P
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index e6289a3..d3c5233 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -816,7 +816,7 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host,
bool enable,
u32 flags = msm_host->mode_flags;
enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
- u32 data = 0;
+ u32 data = 0, lane_ctrl = 0;
if (!enable) {
dsi_write(msm_host, REG_DSI_CTRL, 0);
@@ -904,9 +904,11 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host,
bool enable,
dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(msm_host->dlane_swap));
- if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
+ if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
+ lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
dsi_write(msm_host, REG_DSI_LANE_CTRL,
- DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
+ lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
+ }
data |= DSI_CTRL_ENABLE;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm/radeon: use true,false for bool variable
zhengbin (7): drm/radeon: use true,false for bool variable in r100.c drm/radeon: use true,false for bool variable in si.c drm/radeon: use true,false for bool variable in r600.c drm/radeon: use true,false for bool variable in evergreen.c drm/radeon: use true,false for bool variable in rv770.c drm/radeon: use true,false for bool variable in cik.c drm/radeon: use true,false for bool variable in ni.c drivers/gpu/drm/radeon/cik.c | 4 ++-- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/gpu/drm/radeon/ni.c| 4 ++-- drivers/gpu/drm/radeon/r100.c | 8 drivers/gpu/drm/radeon/r600.c | 2 +- drivers/gpu/drm/radeon/rv770.c | 2 +- drivers/gpu/drm/radeon/si.c| 4 ++-- 7 files changed, 13 insertions(+), 13 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/amd/display: use true, false for bool variable in display_rq_dlg_calc_20.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:110:6-13:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:113:2-9:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:243:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:244:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:267:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:268:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:272:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:273:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:283:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:285:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:673:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c:961:1-9:
WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
.../display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c
index 9df24ec..ca80784 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.c
@@ -107,10 +107,10 @@ static unsigned int get_bytes_per_element(enum
source_format_class source_format
static bool is_dual_plane(enum source_format_class source_format)
{
- bool ret_val = 0;
+ bool ret_val = false;
if ((source_format == dm_420_8) || (source_format == dm_420_10))
- ret_val = 1;
+ ret_val = true;
return ret_val;
}
@@ -240,8 +240,8 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
unsigned int swath_bytes_c = 0;
unsigned int full_swath_bytes_packed_l = 0;
unsigned int full_swath_bytes_packed_c = 0;
- bool req128_l = 0;
- bool req128_c = 0;
+ bool req128_l = false;
+ bool req128_c = false;
bool surf_linear = (pipe_src_param.sw_mode == dm_sw_linear);
bool surf_vert = (pipe_src_param.source_scan == dm_vert);
unsigned int log2_swath_height_l = 0;
@@ -264,13 +264,13 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
total_swath_bytes = 2 * full_swath_bytes_packed_l + 2 *
full_swath_bytes_packed_c;
if (total_swath_bytes <= detile_buf_size_in_bytes) { //full
256b request
- req128_l = 0;
- req128_c = 0;
+ req128_l = false;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l;
swath_bytes_c = full_swath_bytes_packed_c;
} else { //128b request (for luma only for yuv420 8bpc)
- req128_l = 1;
- req128_c = 0;
+ req128_l = true;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l / 2;
swath_bytes_c = full_swath_bytes_packed_c;
}
@@ -280,9 +280,9 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
total_swath_bytes = 2 * full_swath_bytes_packed_l;
if (total_swath_bytes <= detile_buf_size_in_bytes)
- req128_l = 0;
+ req128_l = false;
else
- req128_l = 1;
+ req128_l = true;
swath_bytes_l = total_swath_bytes;
swath_bytes_c = 0;
@@ -670,7 +670,7 @@ static void get_surf_rq_param(struct display_mode_lib
*mode_lib,
const display_pipe_source_params_st pipe_src_param,
bool is_chroma)
{
- bool mode_422 = 0;
+ bool mode_422 = false;
unsigned int vp_width = 0;
unsigned int vp_height = 0;
unsigned int data_pitch = 0;
@@ -958,7 +958,7 @@ static void dml20_rq_dlg_get_dlg_params(struct
display_mode_lib *mode_lib,
// Source
// dcc_en = src.dcc;
dual_plane = is_dual_plane((enum
source_format_class)(src->source_format));
- mode_422 = 0; // TODO
+
[PATCH 4/7] drm/radeon: use true, false for bool variable in evergreen.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/evergreen.c:4948:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/evergreen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 683c790..14d90dc 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -4945,7 +4945,7 @@ static void evergreen_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] phy: Add DisplayPort configuration options
Hi,
> -Original Message-
> From: Maxime Ripard
> Sent: Monday, December 23, 2019 22:49
> To: Yuti Suresh Amonkar
> Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> prane...@ti.com; tomi.valkei...@ti.com; jsa...@ti.com; Milind Parab
> ; Swapnil Kashinath Jakhade
>
> Subject: Re: [PATCH v2] phy: Add DisplayPort configuration options
>
> EXTERNAL MAIL
>
>
> Hi,
>
> Please note that I don't have access to the displayPort spec, so I'll only
> comment on the content of that patch, not whether it's complete or not.
>
> On Mon, Dec 23, 2019 at 02:41:13PM +0100, Yuti Amonkar wrote:
> > Allow DisplayPort PHYs to be configured through the generic functions
> > through a custom structure added to the generic union.
> > The configuration structure is used for reconfiguration of DisplayPort
> > PHYs during link training operation.
> >
> > The parameters added here are the ones defined in the DisplayPort spec
> > 1.4 which include link rate, number of lanes, voltage swing and
> > pre-emphasis.
> >
> > Signed-off-by: Yuti Amonkar
> > ---
> >
> > This patch was a part of [1] series earlier but we think that it needs
> > to have a separate attention of the reviewers. Also as both [1] & [2]
> > are dependent on this patch, our sincere request to reviewers to have
> > a faster review of this patch.
> >
> > [1]
> >
> > https://lkml.org/lkml/2019/12/11/455
> >
> > [2]
> >
> > https://patchwork.kernel.org/cover/11271191/
> >
> > include/linux/phy/phy-dp.h | 95
> ++
> > include/linux/phy/phy.h| 4 ++
> > 2 files changed, 99 insertions(+)
> > create mode 100644 include/linux/phy/phy-dp.h
> >
> > diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
> > new file mode 100644 index 000..18cad23
> > --- /dev/null
> > +++ b/include/linux/phy/phy-dp.h
> > @@ -0,0 +1,95 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2019 Cadence Design Systems Inc.
> > + */
> > +
> > +#ifndef __PHY_DP_H_
> > +#define __PHY_DP_H_
> > +
> > +#include
> > +
> > +/**
> > + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
> > + *
> > + * This structure is used to represent the configuration state of a
> > + * DisplayPort phy.
> > + */
> > +struct phy_configure_opts_dp {
> > + /**
> > +* @link_rate:
> > +*
> > +* Link Rate, in Mb/s, of the main link.
> > +*
> > +* Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100
> Mb/s
> > +*/
> > + unsigned int link_rate;
> > +
> > + /**
> > +* @lanes:
> > +*
> > +* Number of active, consecutive, data lanes, starting from
> > +* lane 0, used for the transmissions on main link.
> > +*
> > +* Allowed values: 1, 2, 4
> > +*/
> > + unsigned int lanes;
> > +
> > + /**
> > +* @voltage:
> > +*
> > +* Voltage swing levels, as specified by DisplayPort specification,
> > +* to be used by particular lanes. One value per lane.
> > +* voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
> > +*
> > +* Maximum value: 3
> > +*/
> > + unsigned int voltage[4];
> > +
> > + /**
> > +* @pre:
> > +*
> > +* Pre-emphasis levels, as specified by DisplayPort specification, to be
> > +* used by particular lanes. One value per lane.
> > +*
> > +* Maximum value: 3
> > +*/
> > + unsigned int pre[4];
> > +
> > + /**
> > +* @ssc:
> > +*
> > +* Flag indicating, whether or not to enable spread-spectrum
> clocking.
> > +*
> > +*/
> > + u8 ssc : 1;
> > +
> > + /**
> > +* @set_rate:
> > +*
> > +* Flag indicating, whether or not reconfigure link rate and SSC to
> > +* requested values.
> > +*
> > +*/
> > + u8 set_rate : 1;
> > +
> > + /**
> > +* @set_lanes:
> > +*
> > +* Flag indicating, whether or not reconfigure lane count to
> > +* requested value.
> > +*
> > +*/
> > + u8 set_lanes : 1;
> > +
> > + /**
> > +* @set_voltages:
> > +*
> > +* Flag indicating, whether or not reconfigure voltage swing
> > +* and pre-emphasis to requested values. Only lanes specified
> > +* by "lanes" parameter will be affected.
> > +*
> > +*/
> > + u8 set_voltages : 1;
>
> I'm not quite sure what these flags are supposed to be doing, or what use-
> cases they cover. The current API is using validate to make sure that we can
> have a handshake between the caller and its PHY and must never apply the
> configuration, and configure must always apply the configuration. These
> flags look redundant.
>
> Maxime
These flags are used to reconfigure the link during the link training procedure
as described in DisplayPort spec. In this procedure , we may need to configure
only subset of parameters (VS, Pre-emphasis, link rate and num of lanes)
depending on different phases. e.g. At one stage, we may need to configure only
Voltage swing and Pre-emphasis keeping number of lanes and
[PATCH 7/8] drm/amd/display: use true, false for bool variable in display_rq_dlg_calc_20v2.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:110:6-13:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:113:2-9:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:243:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:244:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:267:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:268:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:272:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:273:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:283:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:285:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:673:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:962:1-9:
WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
.../dc/dml/dcn20/display_rq_dlg_calc_20v2.c| 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c
index 1e6aeb1..287b7a0 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c
@@ -107,10 +107,10 @@ static unsigned int get_bytes_per_element(enum
source_format_class source_format
static bool is_dual_plane(enum source_format_class source_format)
{
- bool ret_val = 0;
+ bool ret_val = false;
if ((source_format == dm_420_8) || (source_format == dm_420_10))
- ret_val = 1;
+ ret_val = true;
return ret_val;
}
@@ -240,8 +240,8 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
unsigned int swath_bytes_c = 0;
unsigned int full_swath_bytes_packed_l = 0;
unsigned int full_swath_bytes_packed_c = 0;
- bool req128_l = 0;
- bool req128_c = 0;
+ bool req128_l = false;
+ bool req128_c = false;
bool surf_linear = (pipe_src_param.sw_mode == dm_sw_linear);
bool surf_vert = (pipe_src_param.source_scan == dm_vert);
unsigned int log2_swath_height_l = 0;
@@ -264,13 +264,13 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
total_swath_bytes = 2 * full_swath_bytes_packed_l + 2 *
full_swath_bytes_packed_c;
if (total_swath_bytes <= detile_buf_size_in_bytes) { //full
256b request
- req128_l = 0;
- req128_c = 0;
+ req128_l = false;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l;
swath_bytes_c = full_swath_bytes_packed_c;
} else { //128b request (for luma only for yuv420 8bpc)
- req128_l = 1;
- req128_c = 0;
+ req128_l = true;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l / 2;
swath_bytes_c = full_swath_bytes_packed_c;
}
@@ -280,9 +280,9 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
total_swath_bytes = 2 * full_swath_bytes_packed_l;
if (total_swath_bytes <= detile_buf_size_in_bytes)
- req128_l = 0;
+ req128_l = false;
else
- req128_l = 1;
+ req128_l = true;
swath_bytes_l = total_swath_bytes;
swath_bytes_c = 0;
@@ -670,7 +670,7 @@ static void get_surf_rq_param(struct display_mode_lib
*mode_lib,
const display_pipe_source_params_st pipe_src_param,
bool is_chroma)
{
- bool mode_422 = 0;
+ bool mode_422 = false;
unsigned int vp_width = 0;
unsigned int vp_height = 0;
unsigned int data_pitch = 0;
@@ -959,7 +959,7 @@ static void dml20v2_rq_dlg_get_dlg_params(struct
display_mode_lib *mode_lib,
// Source
// dcc_en = src.dcc;
dual_plane = is_dual_plane((enum
[PATCH] drm/i915: Re-init lspcon after HPD if lspcon probe failed
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.
So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index fc29046d48ea..e2862e36d0bf 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -28,6 +28,7 @@
#include "i915_drv.h"
#include "intel_display_types.h"
#include "intel_hotplug.h"
+#include "intel_lspcon.h"
/**
* DOC: Hotplug
@@ -336,6 +337,8 @@ static void i915_digport_work_func(struct work_struct *work)
continue;
dig_port = enc_to_dig_port(>base);
+ if (HAS_LSPCON(dev_priv) && !dig_port->lspcon.active)
+ lspcon_init(dig_port);
ret = dig_port->hpd_pulse(dig_port, long_hpd);
if (ret == IRQ_NONE) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v1 0/1] drm: lima: devfreq and cooling device support
On Mon, Dec 16, 2019 at 4:03 AM Chen-Yu Tsai wrote: > > On Mon, Dec 16, 2019 at 5:12 AM Martin Blumenstingl > wrote: > > > > This is my attempt at adding devfreq (and cooling device) support to > > the lima driver. > > I didn't have much time to do in-depth testing. However, I'm sending > > this out early because there are many SoCs with Mali-400/450 GPU so > > I want to avoid duplicating the work with somebody else. > > > > The code is derived from panfrost_devfreq.c which is why I kept the > > Collabora copyright in lima_devfreq.c. Please let me know if I should > > drop this or how I can make it more clear that I "borrowed" the code > > from panfrost. > > I think it's more common to have separate copyright notices. First you > have yours, then a second paragraph stating the code is derived from > foo, and then attach the copyright statements for foo. thank you for the hint! I found other examples that do it like this, so I'll update it. Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Re-init lspcon after HPD if lspcon probe failed
> On Dec 24, 2019, at 01:36, Jani Nikula wrote:
>
> On Tue, 24 Dec 2019, Kai-Heng Feng wrote:
>> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
>> becomes useless and never responds to cable hotplugging:
>> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on
>> port D
>>
>> Seems like the lspcon chip on the system in question only gets powered
>> after the cable is plugged.
>>
>> So let's call lspcon_init() dynamically to properly initialize the
>> lspcon chip and make HDMI port work.
>>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> v2:
>> - Move lspcon_init() inside of intel_dp_hpd_pulse().
>>
>> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index fe31bbfd6c62..eb395b45527e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -6573,6 +6573,7 @@ enum irqreturn
>> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>> {
>> struct intel_dp *intel_dp = _dig_port->dp;
>> +struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>>
>> if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
>> /*
>> @@ -6592,11 +6593,14 @@ intel_dp_hpd_pulse(struct intel_digital_port
>> *intel_dig_port, bool long_hpd)
>>intel_dig_port->base.base.name,
>>long_hpd ? "long" : "short");
>>
>> -if (long_hpd) {
>> +if (long_hpd && intel_dig_port->base.type != INTEL_OUTPUT_DDI) {
>
> With this change, long hpd handling for DDI on platforms that do not
> have LSPCON, or has an active LSPCON, falls through to the short hpd
> handling. That's not what you're after, is it?
You are right, no :(
I'll send a V3.
Kai-Heng
>
>
> BR,
> Jani.
>
>
>> intel_dp->reset_link_params = true;
>> return IRQ_NONE;
>> }
>>
>> +if (long_hpd && HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
>> +lspcon_init(intel_dig_port);
>> +
>> if (intel_dp->is_mst) {
>> if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
>> /*
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/radeon: use true,false for bool variable in r600.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/r600.c:3056:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/r600.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index d2e51a9..cf1ad4d 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -3053,7 +3053,7 @@ static void r600_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v1 0/1] drm: lima: devfreq and cooling device support
Hi Alyssa, On Mon, Dec 16, 2019 at 4:48 PM Alyssa Rosenzweig wrote: > > If so much code is being duplicated over, I'm wondering if it makes > sense for us to move some of the common devfreq code to core DRM > helpers? if you have any recommendation where to put it then please let me know (I am not familiar with the DRM subsystem at all) my initial idea was that the devfreq logic needs the same information that the scheduler needs (whether we're submitting something to be executed, there was a timeout, ...). however, looking at drivers/gpu/drm/scheduler/ this seems pretty stand-alone so I'm not sure it should go there also the Mali-4x0 GPUs have some "PMU" which *may* be used instead of polling the statistics internally so this is where I realize that with my current knowledge I don't know enough about lima, panfrost, DRM or the devfreq subsystem to get a good idea where to put the code. Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Re-init lspcon after HPD if lspcon probe failed
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.
So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.
Signed-off-by: Kai-Heng Feng
---
v2:
- Move lspcon_init() inside of intel_dp_hpd_pulse().
drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe31bbfd6c62..eb395b45527e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6573,6 +6573,7 @@ enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
struct intel_dp *intel_dp = _dig_port->dp;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -6592,11 +6593,14 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
intel_dig_port->base.base.name,
long_hpd ? "long" : "short");
- if (long_hpd) {
+ if (long_hpd && intel_dig_port->base.type != INTEL_OUTPUT_DDI) {
intel_dp->reset_link_params = true;
return IRQ_NONE;
}
+ if (long_hpd && HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
+ lspcon_init(intel_dig_port);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: display: Add Satoz panel
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Add (simple) bindings for its SAT050AT40H12R2 5.0 inch LCD panel. Signed-off-by: Miquel Raynal --- Changes since v1: * New patch .../display/panel/satoz,sat050at40h12r2.yaml | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml diff --git a/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml new file mode 100644 index ..567b32a544f3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/satoz,sat050at40h12r2# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Satoz SAT050AT40H12R2 panel + +maintainers: + - Thierry Reding + +description: |+ + LCD 5.0 inch 800x480 RGB panel. + + This binding is compatible with the simple-panel binding, which is specified + in simple-panel.txt in this directory. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +contains: + const: satoz,sat050at40h12r2 + +required: + - compatible -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/amdgpu: use true, false for bool variable in amdgpu_device.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3961:1-19: WARNING: Assignment of
0/1 to bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3981:1-19: WARNING: Assignment of
0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 080ec18..c1cf744 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3958,7 +3958,7 @@ static bool amdgpu_device_lock_adev(struct amdgpu_device
*adev, bool trylock)
mutex_lock(>lock_reset);
atomic_inc(>gpu_reset_counter);
- adev->in_gpu_reset = 1;
+ adev->in_gpu_reset = true;
switch (amdgpu_asic_reset_method(adev)) {
case AMD_RESET_METHOD_MODE1:
adev->mp1_state = PP_MP1_STATE_SHUTDOWN;
@@ -3978,7 +3978,7 @@ static void amdgpu_device_unlock_adev(struct
amdgpu_device *adev)
{
amdgpu_vf_error_trans_all(adev);
adev->mp1_state = PP_MP1_STATE_NONE;
- adev->in_gpu_reset = 0;
+ adev->in_gpu_reset = false;
mutex_unlock(>lock_reset);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings in yaml format
Document the bindings used for the Cadence MHDP DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
---
.../bindings/display/bridge/cdns,mhdp.yaml | 109 +
1 file changed, 109 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
new file mode 100644
index 000..aed6224
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
@@ -0,0 +1,109 @@
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence MHDP bridge
+
+maintainers:
+ - Swapnil Jakhade
+ - Yuti Amonkar
+
+properties:
+ compatible:
+enum:
+ - cdns,mhdp8546
+ - ti,j721e-mhdp8546
+
+ clocks:
+maxItems: 1
+description:
+ DP bridge clock, it's used by the IP to know how to translate a number of
+ clock cycles into a time (which is used to comply with DP standard
timings
+ and delays).
+
+ reg:
+minItems: 1
+maxItems: 2
+items:
+ - description:
+ Register block of mhdptx apb registers upto PHY mapped
area(AUX_CONFIG_P).
+ The AUX and PMA registers are mapped to associated phy driver.
+ - description:
+ Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
SoCs.
+
+ reg-names:
+minItems: 1
+maxItems: 2
+items:
+ - const: mhdptx
+ - const: j721e-intg
+
+ phys:
+description: see the
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
+
+ phy-names:
+const: dpphy
+
+ ports:
+type: object
+description:
+ Ports as described in Documentation/devicetree/bindings/graph.txt
+properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ port@0:
+ description:
+ input port representing the DP bridge input
+
+ port@1:
+ description:
+ output port representing the DP bridge output
+required:
+ - port@0
+ - port@1
+ - '#address-cells'
+ - '#size-cells'
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - phys
+ - phy-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+mhdp: dp-bridge@f0fb00 {
+compatible = "cdns,mhdp8546";
+reg = <0xf0 0xfb00 0x0 0x100>,
+ <0xf0 0xfc00 0x0 0x200>;
+clocks = <_clock>;
+phys = <_phy>;
+phy-names = "dpphy";
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_bridge_input: endpoint {
+remote-endpoint = <_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_bridge_output: endpoint {
+ remote-endpoint =
<_dp_connector_input>;
+ };
+ };
+ };
+};
+...
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] dt-bindings: display: Add Satoz panel
Satoz is a Chinese TFT manufacturer. Website: http://www.sat-sz.com/English/index.html Add (simple) bindings for its SAT050AT40H12R2 5.0 inch LCD panel. Signed-off-by: Miquel Raynal --- Changes since v2: * None. Changes since v1: * New patch .../display/panel/satoz,sat050at40h12r2.yaml | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml diff --git a/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml new file mode 100644 index ..567b32a544f3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/satoz,sat050at40h12r2.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/satoz,sat050at40h12r2# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Satoz SAT050AT40H12R2 panel + +maintainers: + - Thierry Reding + +description: |+ + LCD 5.0 inch 800x480 RGB panel. + + This binding is compatible with the simple-panel binding, which is specified + in simple-panel.txt in this directory. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +contains: + const: satoz,sat050at40h12r2 + +required: + - compatible -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/amdgpu: use true, false for bool variable in mxgpu_ai.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:253:2-20: WARNING: Assignment of 0/1 to
bool variable
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:265:2-20: WARNING: Assignment of 0/1 to
bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
index 43305af..5fd67e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -250,7 +250,7 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct
*work)
*/
locked = mutex_trylock(>lock_reset);
if (locked)
- adev->in_gpu_reset = 1;
+ adev->in_gpu_reset = true;
do {
if (xgpu_ai_mailbox_peek_msg(adev) == IDH_FLR_NOTIFICATION_CMPL)
@@ -262,7 +262,7 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct
*work)
flr_done:
if (locked) {
- adev->in_gpu_reset = 0;
+ adev->in_gpu_reset = false;
mutex_unlock(>lock_reset);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v1 0/1] drm: lima: devfreq and cooling device support
On Mon, Dec 16, 2019 at 3:51 AM Qiang Yu wrote: [...] > For the code, I think you may need some lock to protect the time records as > there are two kernel threads gp/pp will try to mark GPU busy and several > interrupts try to mark GPU idle. good catch, thank you for this! I assume the reason is that the panfrost GPUs are using a "unified" architecture, while the ones supported by lima don't I'll add locking so I don't run into trouble. Thank you! Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/panel: simple: Add Satoz SAT050AT40H12R2 panel support
Add support for the Satoz SAT050AT40H12R2 RGB panel.
Signed-off-by: Miquel Raynal
---
Changes since v1:
* Switched to display_timing's instead of display_mode.
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ac6f6b5d200d..00538553a188 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2559,6 +2559,31 @@ static const struct panel_desc samsung_ltn140at29_301 = {
},
};
+static const struct display_timing satoz_sat050at40h12r2_timing = {
+ .pixelclock = { 3330, 3330, 5000 },
+ .hactive = {800, 800, 800},
+ .hfront_porch = {16, 210, 354},
+ .hback_porch = {46, 46, 46},
+ .hsync_len = {1, 1, 40},
+ .vactive = {480, 480, 480},
+ .vfront_porch = {7, 22, 147},
+ .vback_porch = {23, 23, 23},
+ .vsync_len = {1, 1, 20},
+};
+
+static const struct panel_desc satoz_sat050at40h12r2 = {
+ .timings = _sat050at40h12r2_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 108,
+ .height = 65,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .reset_time = 10,
+ .reset_wait = 1,
+};
+
static const struct drm_display_mode sharp_ld_d5116z01b_mode = {
.clock = 168480,
.hdisplay = 1920,
@@ -3354,6 +3379,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "samsung,ltn140at29-301",
.data = _ltn140at29_301,
+ }, {
+ .compatible = "satoz,sat050at40h12r2",
+ .data = _sat050at40h12r2,
}, {
.compatible = "sharp,ld-d5116z01b",
.data = _ld_d5116z01b,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: use true, false for bool variable in vega20_hwmgr.c
Fixes coccicheck warning: drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:875:1-31: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c index 5bcf0d6..3b3ec56 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c @@ -872,7 +872,7 @@ static int vega20_override_pcie_parameters(struct pp_hwmgr *hwmgr) "[OverridePcieParameters] Attempt to override pcie params failed!", return ret); - data->pcie_parameters_override = 1; + data->pcie_parameters_override = true; data->pcie_gen_level1 = pcie_gen; data->pcie_width_level1 = pcie_width; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v22 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
From: Jitao Shi
Add documentation for DT properties supported by
ps8640 DSI-eDP converter.
Signed-off-by: Jitao Shi
Acked-by: Rob Herring
Reviewed-by: Philipp Zabel
Signed-off-by: Ulrich Hecht
Signed-off-by: Enric Balletbo i Serra
---
I maintained the ack from Rob Herring and the review from Philipp
because in essence the only thing I did is migrate to YAML format and
check that no errors are reported via dtbs_check. Just let me know if
you're not agree.
Apart from this note that I removed the mode-sel property because is not
used and I renamed sleep-gpios to powerdown-gpios.
Changes in v23: None
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
Changes in v21: None
Changes in v19: None
Changes in v18: None
Changes in v17: None
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
.../bindings/display/bridge/ps8640.yaml | 112 ++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
new file mode 100644
index ..5dff93641bea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ps8640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI DSI to eDP Video Format Converter Device Tree Bindings
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ The PS8640 is a low power MIPI-to-eDP video format converter supporting
+ mobile devices with embedded panel resolutions up to 2048 x 1536. The
+ device accepts a single channel of MIPI DSI v1.1, with up to four lanes
+ plus clock, at a transmission rate up to 1.5Gbit/sec per lane. The
+ device outputs eDP v1.4, one or two lanes, at a link rate of up to
+ 3.24Gbit/sec per lane.
+
+properties:
+ compatible:
+const: parade,ps8640
+
+ reg:
+maxItems: 1
+description: Base I2C address of the device.
+
+ powerdown-gpios:
+maxItems: 1
+description: GPIO connected to active low powerdown.
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset.
+
+ vdd12-supply:
+maxItems: 1
+description: Regulator for 1.2V digital core power.
+
+ vdd33-supply:
+maxItems: 1
+description: Regulator for 3.3V digital core power.
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description: |
+ Video port for DSI input
+
+ port@1:
+type: object
+description: |
+ Video port for eDP output (panel or connector).
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - powerdown-gpios
+ - reset-gpios
+ - vdd12-supply
+ - vdd33-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ps8640: edp-bridge@18 {
+compatible = "parade,ps8640";
+reg = <0x18>;
+powerdown-gpios = < 116 GPIO_ACTIVE_LOW>;
+reset-gpios = < 115 GPIO_ACTIVE_LOW>;
+vdd12-supply = <_fixed_1v2>;
+vdd33-supply = <_vgp2_reg>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+ps8640_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+ps8640_out: endpoint {
+remote-endpoint = <_in>;
+ };
+};
+};
+};
+};
+
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] phy: Add DisplayPort configuration options
Allow DisplayPort PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The configuration structure is used for reconfiguration of
DisplayPort PHYs during link training operation.
The parameters added here are the ones defined in the DisplayPort
spec 1.4 which include link rate, number of lanes, voltage swing
and pre-emphasis.
Signed-off-by: Yuti Amonkar
---
This patch was a part of [1] series earlier but we think that it needs
to have a separate attention of the reviewers. Also as both [1] & [2] are
dependent on this patch, our sincere request to reviewers to have a
faster review of this patch.
[1]
https://lkml.org/lkml/2019/12/11/455
[2]
https://patchwork.kernel.org/cover/11271191/
include/linux/phy/phy-dp.h | 95 ++
include/linux/phy/phy.h| 4 ++
2 files changed, 99 insertions(+)
create mode 100644 include/linux/phy/phy-dp.h
diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
new file mode 100644
index 000..18cad23
--- /dev/null
+++ b/include/linux/phy/phy-dp.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Cadence Design Systems Inc.
+ */
+
+#ifndef __PHY_DP_H_
+#define __PHY_DP_H_
+
+#include
+
+/**
+ * struct phy_configure_opts_dp - DisplayPort PHY configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * DisplayPort phy.
+ */
+struct phy_configure_opts_dp {
+ /**
+* @link_rate:
+*
+* Link Rate, in Mb/s, of the main link.
+*
+* Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100 Mb/s
+*/
+ unsigned int link_rate;
+
+ /**
+* @lanes:
+*
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions on main link.
+*
+* Allowed values: 1, 2, 4
+*/
+ unsigned int lanes;
+
+ /**
+* @voltage:
+*
+* Voltage swing levels, as specified by DisplayPort specification,
+* to be used by particular lanes. One value per lane.
+* voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
+*
+* Maximum value: 3
+*/
+ unsigned int voltage[4];
+
+ /**
+* @pre:
+*
+* Pre-emphasis levels, as specified by DisplayPort specification, to be
+* used by particular lanes. One value per lane.
+*
+* Maximum value: 3
+*/
+ unsigned int pre[4];
+
+ /**
+* @ssc:
+*
+* Flag indicating, whether or not to enable spread-spectrum clocking.
+*
+*/
+ u8 ssc : 1;
+
+ /**
+* @set_rate:
+*
+* Flag indicating, whether or not reconfigure link rate and SSC to
+* requested values.
+*
+*/
+ u8 set_rate : 1;
+
+ /**
+* @set_lanes:
+*
+* Flag indicating, whether or not reconfigure lane count to
+* requested value.
+*
+*/
+ u8 set_lanes : 1;
+
+ /**
+* @set_voltages:
+*
+* Flag indicating, whether or not reconfigure voltage swing
+* and pre-emphasis to requested values. Only lanes specified
+* by "lanes" parameter will be affected.
+*
+*/
+ u8 set_voltages : 1;
+};
+
+#endif /* __PHY_DP_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 15032f14..ba0aab5 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
struct phy;
@@ -46,9 +47,12 @@ enum phy_mode {
*
* @mipi_dphy: Configuration set applicable for phys supporting
* the MIPI_DPHY phy mode.
+ * @dp:Configuration set applicable for phys supporting
+ * the DisplayPort protocol.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
+ struct phy_configure_opts_dpdp;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/radeon: use true,false for bool variable in cik.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/cik.c:8140:2-15: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/radeon/cik.c:8212:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/cik.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 4fa488c..5c42877 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -8137,7 +8137,7 @@ static void cik_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; @@ -8209,7 +8209,7 @@ static void cik_vce_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable vce here. */ - rdev->has_vce = 0; + rdev->has_vce = false; return; } rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/amdgpu: use true, false for bool variable in amdgpu_debugfs.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:132:2-10: WARNING: Assignment of
0/1 to bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:140:2-10: WARNING: Assignment of
0/1 to bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:142:13-21: WARNING: Assignment of
0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 8e6726e..63343bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -129,7 +129,7 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct
file *f,
sh_bank = 0x;
if (instance_bank == 0x3FF)
instance_bank = 0x;
- use_bank = 1;
+ use_bank = true;
} else if (*pos & (1ULL << 61)) {
me = (*pos & GENMASK_ULL(33, 24)) >> 24;
@@ -137,9 +137,9 @@ static int amdgpu_debugfs_process_reg_op(bool read, struct
file *f,
queue = (*pos & GENMASK_ULL(53, 44)) >> 44;
vmid = (*pos & GENMASK_ULL(58, 54)) >> 54;
- use_ring = 1;
+ use_ring = true;
} else {
- use_bank = use_ring = 0;
+ use_bank = use_ring = false;
}
*pos &= (1UL << 22) - 1;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/i915/dp: use true, false for bool variable in intel_dp.c
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: Ma Feng --- drivers/gpu/drm/i915/display/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2f31d22..4fd0fcd 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4903,7 +4903,7 @@ static u8 intel_dp_autotest_video_pattern(struct intel_dp *intel_dp) intel_dp->compliance.test_data.hdisplay = be16_to_cpu(h_width); intel_dp->compliance.test_data.vdisplay = be16_to_cpu(v_height); /* Set test active flag here so userspace doesn't interrupt things */ - intel_dp->compliance.test_active = 1; + intel_dp->compliance.test_active = true; return DP_TEST_ACK; } @@ -4947,7 +4947,7 @@ static u8 intel_dp_autotest_edid(struct intel_dp *intel_dp) } /* Set test active flag here so userspace doesn't interrupt things */ - intel_dp->compliance.test_active = 1; + intel_dp->compliance.test_active = true; return test_result; } -- 2.6.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/amd/display: use true, false for bool variable in display_mode_vba_21.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c:4124:3-28:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c:4128:5-30:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c:5207:3-37:
WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index 945291d..b6d3466 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -4121,11 +4121,11 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
}
for (i = 0; i <= mode_lib->vba.soc.num_states; i++) {
for (k = 0; k <= mode_lib->vba.NumberOfActivePlanes - 1; k++) {
- locals->RequiresDSC[i][k] = 0;
+ locals->RequiresDSC[i][k] = false;
locals->RequiresFEC[i][k] = 0;
if (mode_lib->vba.BlendingAndTiming[k] == k) {
if (mode_lib->vba.Output[k] == dm_hdmi) {
- locals->RequiresDSC[i][k] = 0;
+ locals->RequiresDSC[i][k] = false;
locals->RequiresFEC[i][k] = 0;
locals->OutputBppPerState[i][k] =
TruncToValidBPP(
dml_min(600.0,
mode_lib->vba.PHYCLKPerState[i]) / mode_lib->vba.PixelClockBackEnd[k] * 24,
@@ -5204,7 +5204,7 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
mode_lib->vba.ODMCombineEnabled[k] =
locals->ODMCombineEnablePerState[mode_lib->vba.VoltageLevel][k];
} else {
- mode_lib->vba.ODMCombineEnabled[k] = 0;
+ mode_lib->vba.ODMCombineEnabled[k] = false;
}
mode_lib->vba.DSCEnabled[k] =
locals->RequiresDSC[mode_lib->vba.VoltageLevel][k];
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] phy: Add DisplayPort configuration options
+Kishon
Thanks & Regards,
Yuti Amonkar
> -Original Message-
> From: Yuti Amonkar
> Sent: Monday, December 23, 2019 19:11
> To: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> max...@cerno.tech
> Cc: prane...@ti.com; tomi.valkei...@ti.com; jsa...@ti.com; Milind Parab
> ; Swapnil Kashinath Jakhade
> ; Yuti Suresh Amonkar
> Subject: [PATCH v2] phy: Add DisplayPort configuration options
>
> Allow DisplayPort PHYs to be configured through the generic functions
> through a custom structure added to the generic union.
> The configuration structure is used for reconfiguration of DisplayPort PHYs
> during link training operation.
>
> The parameters added here are the ones defined in the DisplayPort spec 1.4
> which include link rate, number of lanes, voltage swing and pre-emphasis.
>
> Signed-off-by: Yuti Amonkar
> ---
>
> This patch was a part of [1] series earlier but we think that it needs to
> have a
> separate attention of the reviewers. Also as both [1] & [2] are dependent on
> this patch, our sincere request to reviewers to have a faster review of this
> patch.
>
> [1]
>
> https://lkml.org/lkml/2019/12/11/455
>
> [2]
>
> https://patchwork.kernel.org/cover/11271191/
>
> include/linux/phy/phy-dp.h | 95
> ++
> include/linux/phy/phy.h| 4 ++
> 2 files changed, 99 insertions(+)
> create mode 100644 include/linux/phy/phy-dp.h
>
> diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h new
> file mode 100644 index 000..18cad23
> --- /dev/null
> +++ b/include/linux/phy/phy-dp.h
> @@ -0,0 +1,95 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 Cadence Design Systems Inc.
> + */
> +
> +#ifndef __PHY_DP_H_
> +#define __PHY_DP_H_
> +
> +#include
> +
> +/**
> + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * DisplayPort phy.
> + */
> +struct phy_configure_opts_dp {
> + /**
> + * @link_rate:
> + *
> + * Link Rate, in Mb/s, of the main link.
> + *
> + * Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100
> Mb/s
> + */
> + unsigned int link_rate;
> +
> + /**
> + * @lanes:
> + *
> + * Number of active, consecutive, data lanes, starting from
> + * lane 0, used for the transmissions on main link.
> + *
> + * Allowed values: 1, 2, 4
> + */
> + unsigned int lanes;
> +
> + /**
> + * @voltage:
> + *
> + * Voltage swing levels, as specified by DisplayPort specification,
> + * to be used by particular lanes. One value per lane.
> + * voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
> + *
> + * Maximum value: 3
> + */
> + unsigned int voltage[4];
> +
> + /**
> + * @pre:
> + *
> + * Pre-emphasis levels, as specified by DisplayPort specification, to be
> + * used by particular lanes. One value per lane.
> + *
> + * Maximum value: 3
> + */
> + unsigned int pre[4];
> +
> + /**
> + * @ssc:
> + *
> + * Flag indicating, whether or not to enable spread-spectrum
> clocking.
> + *
> + */
> + u8 ssc : 1;
> +
> + /**
> + * @set_rate:
> + *
> + * Flag indicating, whether or not reconfigure link rate and SSC to
> + * requested values.
> + *
> + */
> + u8 set_rate : 1;
> +
> + /**
> + * @set_lanes:
> + *
> + * Flag indicating, whether or not reconfigure lane count to
> + * requested value.
> + *
> + */
> + u8 set_lanes : 1;
> +
> + /**
> + * @set_voltages:
> + *
> + * Flag indicating, whether or not reconfigure voltage swing
> + * and pre-emphasis to requested values. Only lanes specified
> + * by "lanes" parameter will be affected.
> + *
> + */
> + u8 set_voltages : 1;
> +};
> +
> +#endif /* __PHY_DP_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index
> 15032f14..ba0aab5 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -16,6 +16,7 @@
> #include
> #include
>
> +#include
> #include
>
> struct phy;
> @@ -46,9 +47,12 @@ enum phy_mode {
> *
> * @mipi_dphy: Configuration set applicable for phys supporting
> * the MIPI_DPHY phy mode.
> + * @dp: Configuration set applicable for phys supporting
> + * the DisplayPort protocol.
> */
> union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> + struct phy_configure_opts_dpdp;
> };
>
> /**
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/radeon: use true,false for bool variable in r100.c
Fixes coccicheck warning:
drivers/gpu/drm/radeon/r100.c:1826:3-31: WARNING: Assignment of 0/1 to bool
variable
drivers/gpu/drm/radeon/r100.c:1828:3-31: WARNING: Assignment of 0/1 to bool
variable
drivers/gpu/drm/radeon/r100.c:2390:2-22: WARNING: Assignment of 0/1 to bool
variable
drivers/gpu/drm/radeon/r100.c:2395:2-22: WARNING: Assignment of 0/1 to bool
variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/radeon/r100.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 29c966f..2c1166d 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1823,9 +1823,9 @@ static int r100_packet0_check(struct radeon_cs_parser *p,
case RADEON_PP_TXFORMAT_2:
i = (reg - RADEON_PP_TXFORMAT_0) / 24;
if (idx_value & RADEON_TXFORMAT_NON_POWER2) {
- track->textures[i].use_pitch = 1;
+ track->textures[i].use_pitch = true;
} else {
- track->textures[i].use_pitch = 0;
+ track->textures[i].use_pitch = false;
track->textures[i].width = 1 << ((idx_value &
RADEON_TXFORMAT_WIDTH_MASK) >> RADEON_TXFORMAT_WIDTH_SHIFT);
track->textures[i].height = 1 << ((idx_value &
RADEON_TXFORMAT_HEIGHT_MASK) >> RADEON_TXFORMAT_HEIGHT_SHIFT);
}
@@ -2387,12 +2387,12 @@ void r100_cs_track_clear(struct radeon_device *rdev,
struct r100_cs_track *track
else
track->num_texture = 6;
track->maxy = 2048;
- track->separate_cube = 1;
+ track->separate_cube = true;
} else {
track->num_cb = 4;
track->num_texture = 16;
track->maxy = 4096;
- track->separate_cube = 0;
+ track->separate_cube = false;
track->aaresolve = false;
track->aa.robj = NULL;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/amdgpu: use true,false for bool variable
zhengbin (5): drm/amdgpu: use true,false for bool variable in mxgpu_ai.c drm/amdgpu: use true,false for bool variable in mxgpu_nv.c drm/amdgpu: use true,false for bool variable in amdgpu_device.c drm/amdgpu: use true,false for bool variable in amdgpu_debugfs.c drm/amdgpu: use true,false for bool variable in amdgpu_psp.c drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++-- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 4 ++-- 5 files changed, 15 insertions(+), 15 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.
This patch series adds new DRM driver for Cadence Display Port. The Cadence Display Port is also referred as MHDP (Mobile High Definition Link, High-Definition Multimedia Interface Display Port) Cadence Display Port complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards This driver implements Single Stream Transport (SST) support. Adds Texas Instruments SoC J721e specific wrapper and adds the device tree bindings in YAML format. The patch series has three patches which applies the changes in the below sequence 1. 001-dt-bindings-drm-bridge-Document-Cadence-MHDP-bridge-bindings-in-yaml-format Documents the bindings in yaml format. 2. 002-drm-bridge-Add-support-for-Cadence-MHDP-bridge This patch adds new DRM driver for Cadence MHDP Display Port. The patch implements supports for single stream transport mode. 3. 003-drm-mhdp-add-j721e-wrapper Add Texas Instruments (TI) j721e wrapper for mhdp. The wrapper configures mhdp clocks and muxes as required by SoC. Version History: v2: - Use enum in compatible property of YAML file. - Add reg-names property to YAML file - Add minItems and maxItems to reg property in YAML. - Remove cdns_mhdp_link_probe function to remove duplication of reading dpcd capabilities. This patch series is dependent on PHY DisplayPort configuration patch [1] [1] https://patchwork.kernel.org/patch/11307829/ Yuti Amonkar (3): dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings in yaml format drm: bridge: Add support for Cadence MHDP DPI/DP bridge drm/mhdp: add j721e wrapper .../bindings/display/bridge/cdns,mhdp.yaml | 109 + drivers/gpu/drm/bridge/Kconfig | 21 + drivers/gpu/drm/bridge/Makefile|6 + drivers/gpu/drm/bridge/cdns-mhdp-j721e.c | 79 + drivers/gpu/drm/bridge/cdns-mhdp-j721e.h | 55 + drivers/gpu/drm/bridge/cdns-mhdp.c | 2214 drivers/gpu/drm/bridge/cdns-mhdp.h | 381 7 files changed, 2865 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.c create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.h create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: vmalloc-out-of-bounds Write in drm_fb_helper_dirty_work
Hello, syzbot found the following crash on: HEAD commit:62104694 Merge branch 'parisc-5.5-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1711b6c1e0 kernel config: https://syzkaller.appspot.com/x/.config?x=1b59a3066828ac4c dashboard link: https://syzkaller.appspot.com/bug?extid=fd418471717e1e1aa783 compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fd418471717e1e1aa...@syzkaller.appspotmail.com == BUG: KASAN: vmalloc-out-of-bounds in memcpy include/linux/string.h:380 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:399 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_work+0x44c/0x780 drivers/gpu/drm/drm_fb_helper.c:428 Write of size 4064 at addr c9000adea020 by task kworker/2:2/8685 CPU: 2 PID: 8685 Comm: kworker/2:2 Not tainted 5.5.0-rc2-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Workqueue: events drm_fb_helper_dirty_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memcpy+0x38/0x50 mm/kasan/common.c:126 memcpy include/linux/string.h:380 [inline] drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:399 [inline] drm_fb_helper_dirty_work+0x44c/0x780 drivers/gpu/drm/drm_fb_helper.c:428 process_one_work+0x9af/0x1740 kernel/workqueue.c:2264 worker_thread+0x98/0xe40 kernel/workqueue.c:2410 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Memory state around the buggy address: c9000ade9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c9000ade9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c9000adea000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 ^ c9000adea080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 c9000adea100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/amd/display: use true, false for bool variable in display_rq_dlg_calc_21.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:85:6-13:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:88:2-9:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:225:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:226:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:251:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:252:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:256:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:257:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:267:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:269:3-11:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:682:6-14:
WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1013:1-9:
WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
.../display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
index e60af38..a38baa7 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
@@ -82,10 +82,10 @@ static unsigned int get_bytes_per_element(enum
source_format_class source_format
static bool is_dual_plane(enum source_format_class source_format)
{
- bool ret_val = 0;
+ bool ret_val = false;
if ((source_format == dm_420_8) || (source_format == dm_420_10))
- ret_val = 1;
+ ret_val = true;
return ret_val;
}
@@ -222,8 +222,8 @@ static void handle_det_buf_split(
unsigned int swath_bytes_c = 0;
unsigned int full_swath_bytes_packed_l = 0;
unsigned int full_swath_bytes_packed_c = 0;
- bool req128_l = 0;
- bool req128_c = 0;
+ bool req128_l = false;
+ bool req128_c = false;
bool surf_linear = (pipe_src_param.sw_mode == dm_sw_linear);
bool surf_vert = (pipe_src_param.source_scan == dm_vert);
unsigned int log2_swath_height_l = 0;
@@ -248,13 +248,13 @@ static void handle_det_buf_split(
total_swath_bytes = 2 * full_swath_bytes_packed_l + 2 *
full_swath_bytes_packed_c;
if (total_swath_bytes <= detile_buf_size_in_bytes) { //full
256b request
- req128_l = 0;
- req128_c = 0;
+ req128_l = false;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l;
swath_bytes_c = full_swath_bytes_packed_c;
} else { //128b request (for luma only for yuv420 8bpc)
- req128_l = 1;
- req128_c = 0;
+ req128_l = true;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l / 2;
swath_bytes_c = full_swath_bytes_packed_c;
}
@@ -264,9 +264,9 @@ static void handle_det_buf_split(
total_swath_bytes = 2 * full_swath_bytes_packed_l;
if (total_swath_bytes <= detile_buf_size_in_bytes)
- req128_l = 0;
+ req128_l = false;
else
- req128_l = 1;
+ req128_l = true;
swath_bytes_l = total_swath_bytes;
swath_bytes_c = 0;
@@ -679,7 +679,7 @@ static void get_surf_rq_param(
const display_pipe_params_st pipe_param,
bool is_chroma)
{
- bool mode_422 = 0;
+ bool mode_422 = false;
unsigned int vp_width = 0;
unsigned int vp_height = 0;
unsigned int data_pitch = 0;
@@ -1010,7 +1010,7 @@ static void dml_rq_dlg_get_dlg_params(
// Source
// dcc_en = src.dcc;
dual_plane = is_dual_plane((enum source_format_class)
(src->source_format));
- mode_422 = 0; // FIXME
+ mode_422 = false; // FIXME
access_dir = (src->source_scan == dm_vert); // vp access direction:
horizontal or vertical accessed
[PATCH 0/8] drm/amd/display: use true,false for bool variable
zhengbin (8): drm/amd/display: use true,false for bool variable in dc_link_ddc.c drm/amd/display: use true,false for bool variable in dcn10_hw_sequencer.c drm/amd/display: use true,false for bool variable in dcn20_hwseq.c drm/amd/display: use true,false for bool variable in display_mode_vba_21.c drm/amd/display: use true,false for bool variable in dce_calcs.c drm/amd/display: use true,false for bool variable in display_rq_dlg_calc_20.c drm/amd/display: use true,false for bool variable in display_rq_dlg_calc_20v2.c drm/amd/display: use true,false for bool variable in display_rq_dlg_calc_21.c drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 24 +++--- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 4 ++-- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 ++-- .../display/dc/dml/dcn20/display_rq_dlg_calc_20.c | 24 +++--- .../dc/dml/dcn20/display_rq_dlg_calc_20v2.c| 24 +++--- .../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 6 +++--- .../display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 24 +++--- 8 files changed, 56 insertions(+), 56 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.
So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
Signed-off-by: Kai-Heng Feng
---
v3:
- Make sure it's handled under long HPD case.
v2:
- Move lspcon_init() inside of intel_dp_hpd_pulse().
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe31bbfd6c62..a72c9c041c60 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6573,6 +6573,7 @@ enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
struct intel_dp *intel_dp = _dig_port->dp;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
/*
@@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
long_hpd ? "long" : "short");
if (long_hpd) {
- intel_dp->reset_link_params = true;
+ if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
+ HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
+ lspcon_init(intel_dig_port);
+ else
+ intel_dp->reset_link_params = true;
+
return IRQ_NONE;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/i915: use true, false for bool variable in i915_debugfs.c
Fixes coccicheck warning: drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: Ma Feng --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d28468e..4ead86a 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3075,9 +3075,9 @@ static ssize_t i915_displayport_test_active_write(struct file *file, * testing code, only accept an actual value of 1 here */ if (val == 1) - intel_dp->compliance.test_active = 1; + intel_dp->compliance.test_active = true; else - intel_dp->compliance.test_active = 0; + intel_dp->compliance.test_active = false; } } drm_connector_list_iter_end(_iter); -- 2.6.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/radeon: use true,false for bool variable in rv770.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/rv770.c:1706:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/rv770.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index 3fc461d..21f653a 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -1703,7 +1703,7 @@ static void rv770_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/mhdp: add j721e wrapper
Add j721e wrapper for mhdp, which sets up the clock and data muxes.
Signed-off-by: Yuti Amonkar
---
drivers/gpu/drm/bridge/Kconfig | 10
drivers/gpu/drm/bridge/Makefile | 3 ++
drivers/gpu/drm/bridge/cdns-mhdp-j721e.c | 79
drivers/gpu/drm/bridge/cdns-mhdp-j721e.h | 55 ++
drivers/gpu/drm/bridge/cdns-mhdp.c | 14 +-
drivers/gpu/drm/bridge/cdns-mhdp.h | 1 +
6 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 616c05f..4b6799b 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,16 @@ config DRM_CDNS_MHDP
It takes a DPI stream as input and output it encoded
in DP format.
+if DRM_CDNS_MHDP
+
+config DRM_CDNS_MHDP_J721E
+ bool "J721E Cadence DPI/DP wrapper support"
+ default y
+ help
+ Support J721E Cadence DPI/DP wrapper.It sets up
+ the clock and data muxes.
+endif
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c1a0da7..d358184 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -20,3 +20,6 @@ obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
obj-y += synopsys/
mhdp8546-objs := cdns-mhdp.o
+ifeq ($(CONFIG_DRM_CDNS_MHDP_J721E),y)
+ mhdp8546-objs += cdns-mhdp-j721e.o
+endif
diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
new file mode 100644
index 000..a87faf5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI j721e Cadence MHDP DP wrapper
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Jyri Sarha
+#include
+
+#include "cdns-mhdp-j721e.h"
+
+#defineREVISION0x00
+#defineDPTX_IPCFG 0x04
+#defineECC_MEM_CFG 0x08
+#defineDPTX_DSC_CFG0x0c
+#defineDPTX_SRC_CFG0x10
+#defineDPTX_VIF_SECURE_MODE_CFG0x14
+#defineDPTX_VIF_CONN_STATUS0x18
+#definePHY_CLK_STATUS 0x1c
+
+#define DPTX_SRC_AIF_ENBIT(16)
+#define DPTX_SRC_VIF_3_IN30B BIT(11)
+#define DPTX_SRC_VIF_2_IN30B BIT(10)
+#define DPTX_SRC_VIF_1_IN30B BIT(9)
+#define DPTX_SRC_VIF_0_IN30B BIT(8)
+#define DPTX_SRC_VIF_3_SEL_DPI5BIT(7)
+#define DPTX_SRC_VIF_3_SEL_DPI30
+#define DPTX_SRC_VIF_2_SEL_DPI4BIT(6)
+#define DPTX_SRC_VIF_2_SEL_DPI20
+#define DPTX_SRC_VIF_1_SEL_DPI3BIT(5)
+#define DPTX_SRC_VIF_1_SEL_DPI10
+#define DPTX_SRC_VIF_0_SEL_DPI2BIT(4)
+#define DPTX_SRC_VIF_0_SEL_DPI00
+#define DPTX_SRC_VIF_3_EN BIT(3)
+#define DPTX_SRC_VIF_2_EN BIT(2)
+#define DPTX_SRC_VIF_1_EN BIT(1)
+#define DPTX_SRC_VIF_0_EN BIT(0)
+
+/* TODO turn DPTX_IPCFG fw_mem_clk_en at pm_runtime_suspend. */
+
+int cdns_mhdp_j721e_init(struct cdns_mhdp_device *mhdp)
+{
+ struct platform_device *pdev = to_platform_device(mhdp->dev);
+ struct resource *regs;
+
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ mhdp->j721e_regs = devm_ioremap_resource(>dev, regs);
+ if (IS_ERR(mhdp->j721e_regs))
+ return PTR_ERR(mhdp->j721e_regs);
+
+ return 0;
+}
+
+void cdns_mhdp_j721e_fini(struct cdns_mhdp_device *mhdp)
+{
+}
+
+void cdns_mhdp_j721e_enable(struct cdns_mhdp_device *mhdp)
+{
+ /*
+* Eneble VIF_0 and select DPI2 as its input. DSS0 DPI0 is connected
+* to eDP DPI2. This is the only supported SST configuration on
+* J721E.
+*/
+ writel(DPTX_SRC_VIF_0_EN | DPTX_SRC_VIF_0_SEL_DPI2,
+ mhdp->j721e_regs + DPTX_SRC_CFG);
+}
+
+void cdns_mhdp_j721e_disable(struct cdns_mhdp_device *mhdp)
+{
+ /* Put everything to defaults */
+ writel(0, mhdp->j721e_regs + DPTX_DSC_CFG);
+}
diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-j721e.h
b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.h
new file mode 100644
index 000..bd53508
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI j721e Cadence MHDP DP wrapper
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Jyri Sarha
+#include "cdns-mhdp.h"
+
+struct cdns_mhdp_j721e_wrap;
+
+#ifdef CONFIG_DRM_CDNS_MHDP_J721E
+
+int cdns_mhdp_j721e_init(struct cdns_mhdp_device
Re: [Freedreno] [v1] drm/msm: update LANE_CTRL register value from default value
On Mon, Dec 23, 2019 at 3:19 AM Harigovindan P wrote:
>
> Updating REG_DSI_LANE_CTRL register value by reading default
> register value and writing it back using bitwise OR with
> DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST. This works for all panels.
Why?
You explain what the code does, which I can tell from reading the
code. The commit text should tell me why this change is necessary.
Why would I care if this change is in my tree or not? What feature
does it provide or what issue does it fix?
>
> Signed-off-by: Harigovindan P
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e6289a3..d3c5233 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -816,7 +816,7 @@ static void dsi_ctrl_config(struct msm_dsi_host
> *msm_host, bool enable,
> u32 flags = msm_host->mode_flags;
> enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
> const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
> - u32 data = 0;
> + u32 data = 0, lane_ctrl = 0;
>
> if (!enable) {
> dsi_write(msm_host, REG_DSI_CTRL, 0);
> @@ -904,9 +904,11 @@ static void dsi_ctrl_config(struct msm_dsi_host
> *msm_host, bool enable,
> dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
> DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(msm_host->dlane_swap));
>
> - if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
> + if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
> + lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
> dsi_write(msm_host, REG_DSI_LANE_CTRL,
> - DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
> + lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
> + }
>
> data |= DSI_CTRL_ENABLE;
>
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/amdgpu: use true, false for bool variable in amdgpu_psp.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:674:2-26: WARNING: Assignment of 0/1 to
bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:794:1-25: WARNING: Assignment of 0/1 to
bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:897:2-36: WARNING: Assignment of 0/1 to
bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:1016:1-35: WARNING: Assignment of 0/1
to bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:1087:2-34: WARNING: Assignment of 0/1
to bool variable
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:1177:1-33: WARNING: Assignment of 0/1
to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 3e293a3..9153b9a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -671,7 +671,7 @@ static int psp_ras_load(struct psp_context *psp)
psp->fence_buf_mc_addr);
if (!ret) {
- psp->ras.ras_initialized = 1;
+ psp->ras.ras_initialized = true;
psp->ras.session_id = cmd->resp.session_id;
}
@@ -791,7 +791,7 @@ static int psp_ras_terminate(struct psp_context *psp)
if (ret)
return ret;
- psp->ras.ras_initialized = 0;
+ psp->ras.ras_initialized = false;
/* free ras shared memory */
amdgpu_bo_free_kernel(>ras.ras_shared_bo,
@@ -894,7 +894,7 @@ static int psp_hdcp_load(struct psp_context *psp)
ret = psp_cmd_submit_buf(psp, NULL, cmd, psp->fence_buf_mc_addr);
if (!ret) {
- psp->hdcp_context.hdcp_initialized = 1;
+ psp->hdcp_context.hdcp_initialized = true;
psp->hdcp_context.session_id = cmd->resp.session_id;
}
@@ -1013,7 +1013,7 @@ static int psp_hdcp_terminate(struct psp_context *psp)
if (ret)
return ret;
- psp->hdcp_context.hdcp_initialized = 0;
+ psp->hdcp_context.hdcp_initialized = false;
/* free hdcp shared memory */
amdgpu_bo_free_kernel(>hdcp_context.hdcp_shared_bo,
@@ -1084,7 +1084,7 @@ static int psp_dtm_load(struct psp_context *psp)
ret = psp_cmd_submit_buf(psp, NULL, cmd, psp->fence_buf_mc_addr);
if (!ret) {
- psp->dtm_context.dtm_initialized = 1;
+ psp->dtm_context.dtm_initialized = true;
psp->dtm_context.session_id = cmd->resp.session_id;
}
@@ -1174,7 +1174,7 @@ static int psp_dtm_terminate(struct psp_context *psp)
if (ret)
return ret;
- psp->dtm_context.dtm_initialized = 0;
+ psp->dtm_context.dtm_initialized = false;
/* free hdcp shared memory */
amdgpu_bo_free_kernel(>dtm_context.dtm_shared_bo,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/radeon: use true,false for bool variable in si.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/si.c:6475:2-15: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/radeon/si.c:6542:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/si.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 8788a05..93dcab5 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -6472,7 +6472,7 @@ static void si_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; @@ -6539,7 +6539,7 @@ static void si_vce_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable vce here. */ - rdev->has_vce = 0; + rdev->has_vce = false; return; } rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: task hung in fb_release
syzbot has bisected this bug to:
commit e3933f26b657c341055443103bad331f4537b113
Author: Rex Zhu
Date: Tue Jan 16 10:35:15 2018 +
drm/amd/pp: Add edit/commit/show OD clock/voltage support in sysfs
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12b5a799e0
start commit: c6017471 Merge tag 'xfs-5.5-fixes-2' of git://git.kernel.o..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=11b5a799e0
console output: https://syzkaller.appspot.com/x/log.txt?x=16b5a799e0
kernel config: https://syzkaller.appspot.com/x/.config?x=7f6119e2e3675a73
dashboard link: https://syzkaller.appspot.com/bug?extid=d130c4a0890561cfac5b
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=169b1925e0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12b9623ee0
Reported-by: syzbot+d130c4a0890561cfa...@syzkaller.appspotmail.com
Fixes: e3933f26b657 ("drm/amd/pp: Add edit/commit/show OD clock/voltage
support in sysfs")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/amd/display: use true, false for bool variable in dcn20_hwseq.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c:186:6-14: WARNING:
Assignment of 0/1 to bool variable
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c:189:2-10: WARNING:
Assignment of 0/1 to bool variable
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
index aa00fbe..5b9cbeda 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
@@ -183,10 +183,10 @@ void dcn20_enable_power_gating_plane(
struct dce_hwseq *hws,
bool enable)
{
- bool force_on = 1; /* disable power gating */
+ bool force_on = true; /* disable power gating */
if (enable)
- force_on = 0;
+ force_on = false;
/* DCHUBP0/1/2/3/4/5 */
REG_UPDATE(DOMAIN0_PG_CONFIG, DOMAIN0_POWER_FORCEON, force_on);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e SoC.
MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
embedded Display Port (eDP) standards.It integrates uCPU running the
embedded Firmware(FW) interfaced over APB interface.
Basically, it takes a DPI stream as input and output it encoded in DP
format. Currently, it supports only SST mode.
Signed-off-by: Yuti Amonkar
---
drivers/gpu/drm/bridge/Kconfig | 11 +
drivers/gpu/drm/bridge/Makefile|3 +
drivers/gpu/drm/bridge/cdns-mhdp.c | 2202
drivers/gpu/drm/bridge/cdns-mhdp.h | 380 +++
4 files changed, 2596 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..616c05f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -37,6 +37,17 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+ It takes a DPI stream as input and output it encoded
+ in DP format.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..c1a0da7 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
obj-y += synopsys/
+
+mhdp8546-objs := cdns-mhdp.o
diff --git a/drivers/gpu/drm/bridge/cdns-mhdp.c
b/drivers/gpu/drm/bridge/cdns-mhdp.c
new file mode 100644
index 000..543ce80
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-mhdp.c
@@ -0,0 +1,2202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence MHDP DP bridge driver.
+ *
+ * Copyright: 2019 Cadence Design Systems, Inc.
+ *
+ * Author: Quentin Schulz
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "cdns-mhdp.h"
+
+static const struct of_device_id mhdp_ids[] = {
+ { .compatible = "cdns,mhdp8546", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mhdp_ids);
+
+static inline u32 get_unaligned_be24(const void *p)
+{
+ const u8 *_p = p;
+
+ return _p[0] << 16 | _p[1] << 8 | _p[2];
+}
+
+static inline void put_unaligned_be24(u32 val, void *p)
+{
+ u8 *_p = p;
+
+ _p[0] = val >> 16;
+ _p[1] = val >> 8;
+ _p[2] = val;
+}
+
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
+{
+ int val, ret;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
+val, !val, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(mhdp->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ writel(val, mhdp->regs + CDNS_MAILBOX_TX_DATA);
+
+ return 0;
+}
+
+static int cdns_mhdp_mailbox_validate_receive(struct cdns_mhdp_device *mhdp,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+ u32 mbox_size, i;
+ u8 header[4];
+ int ret;
+
+ /* read the header of the message */
+ for (i = 0; i < 4; i++) {
+ ret = cdns_mhdp_mailbox_read(mhdp);
+ if (ret < 0)
+ return ret;
+
+ header[i] = ret;
+ }
+
+ mbox_size = get_unaligned_be16(header + 2);
+
+ if (opcode != header[0] || module_id != header[1] ||
+ req_size != mbox_size) {
+ /*
+* If the message in mailbox is not what we want, we need to
+* clear the mailbox by reading its contents.
+*/
[PATCH 7/7] drm/radeon: use true,false for bool variable in ni.c
Fixes coccicheck warning: drivers/gpu/drm/radeon/ni.c:2020:2-15: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/radeon/ni.c:2088:2-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/radeon/ni.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index a99442b..02feb08 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -2017,7 +2017,7 @@ static void cayman_uvd_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable uvd here. */ - rdev->has_uvd = 0; + rdev->has_uvd = false; return; } rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL; @@ -2085,7 +2085,7 @@ static void cayman_vce_init(struct radeon_device *rdev) * there. So it is pointless to try to go through that code * hence why we disable vce here. */ - rdev->has_vce = 0; + rdev->has_vce = false; return; } rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_obj = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v22 0/2] drm/bridge: PS8640 MIPI-to-eDP bridge
Hi all,
This is another version of the driver. Note that the driver changed
significally and is a more simply because now is using the panel_bridge
helpers. Apart from this, I addressed the comments from Maxime, Laurent
and Ezequiel.
This bridge is required to have the embedded display working on an Acer
Chromebook R13 ("Elm"). Hopefully we are a bit more close to have this
driver merged. If more changes are required, please let me know and I
will work on it.
Note: Along these around 20 revisions of this driver I was unable to
reconstruct the full changelog history, so I'm skipping this. Sorry
about that, I promise I'll maintain the changelog for future revisions.
Thanks,
Enric
Changes in v23:
- Merge mute/unmute functions into one (Nicolas Boichat)
- Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia)
- Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat and
Enric)
- Add space between address and address parameter 'address%02x' (Nicolas
Boichat)
- Add Tested-by Hsin-Yi
- Added me as author after the refactor
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
- Remove sysfs attributes because are not really used (Enric Balletbo)
- Use enum for address page offsets (Ezequiel Garcia)
- Remove enable tracking (Enric Balletbo)
- Use panel_bridge API (Laurent Pinchart)
- Do not use kernel-doc format for non kernel-doc formatted commands (Enric
Balletbo)
- Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia)
- Use time_is_after_jiffies idiom (Ezequiel Garcia)
- Remove unused macros (Ezequiel Garcia)
- Fix weird alignment in dsi->mode_flags (Laurent Pinchart)
- Use drm_of_find_panel_or_bridge helper (Laurent Pinchart)
- Remove mode-sel-gpios as is not used (Laurent Pinchart)
- Remove error messages to get gpios as the core will already report it (Enric
Balletbo)
- Remove redundant message getting the regulators (Laurent Pinchart)
- Rename sleep-gpios to powerdown-gpios (Laurent Pinchart)
- Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent
Pinchart)
- Fix race with userspace accessing the sysfs attributes (Laurent Pinchart)
- Remove id_table as is only used on DR platforms (Laurent Pinchart)
- Convert to new i2c device probe() (Laurent Pinchart)
- Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart)
- Remove unnused global variables (Laurent Pinchart)
- Remove unnused fields in ps8640 struct (Laurent Pinchart)
- Remove commented-out headers (Laurent Pinchart)
Changes in v21:
- Use devm_i2c_new_dummy_device and fix build issue using deprecated
i2c_new_dummy
- Fix build issue due missing drm_bridge.h
- Do not remove in ps8640_remove device managed resources
Changes in v19:
- fixed return value of ps8640_probe() when no panel is found
Changes in v18:
- followed DRM API changes
- use DEVICE_ATTR_RO()
- remove firmware update code
- add SPDX identifier
Changes in v17:
- remove some unused head files.
- add macros for ps8640 pages.
- remove ddc_i2c client
- add mipi_dsi_device_register_full
- remove the manufacturer from the name and i2c_device_id
Changes in v16:
- Disable ps8640 DSI MCS Function.
- Rename gpios name more clearly.
- Tune the ps8640 power on sequence.
Changes in v15:
- Drop drm_connector_(un)register calls from parade ps8640.
The main DRM driver mtk_drm_drv now calls
drm_connector_register_all() after drm_dev_register() in the
mtk_drm_bind() function. That function should iterate over all
connectors and call drm_connector_register() for each of them.
So, remove drm_connector_(un)register calls from parade ps8640.
Changes in v14:
- update copyright info.
- change bridge_to_ps8640 and connector_to_ps8640 to inline function.
- fix some coding style.
- use sizeof as array counter.
- use drm_get_edid when read edid.
- add mutex when firmware updating.
Changes in v13:
- add const on data, ps8640_write_bytes(struct i2c_client *client, const u8
*data, u16 data_len)
- fix PAGE2_SW_REST tyro.
- move the buf[3] init to entrance of the function.
Changes in v12:
- fix hw_chip_id build warning
Changes in v11:
- Remove depends on I2C, add DRM depends
- Reuse ps8640_write_bytes() in ps8640_write_byte()
- Use timer check for polling like the routines in
- Fix no drm_connector_unregister/drm_connector_cleanup when
ps8640_bridge_attach fail
- Check the ps8640 hardware id in ps8640_validate_firmware
- Remove fw_version check
- Move ps8640_validate_firmware before ps8640_enter_bl
- Add ddc_i2c unregister when probe fail and ps8640_remove
Jitao Shi (2):
Documentation: bridge: Add documentation for ps8640 DT properties
drm/bridge: Add I2C based driver for ps8640 bridge
.../bindings/display/bridge/ps8640.yaml | 112 ++
drivers/gpu/drm/bridge/Kconfig| 11 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/parade-ps8640.c
RE: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal
>-Original Message- >From: dri-devel On Behalf Of Lucas De >Marchi >Sent: Wednesday, December 18, 2019 1:09 AM >To: Roper, Matthew D >Cc: Lisovskiy, Stanislav ; David Airlie >; Laxminarayan Bharadiya, Pankaj >; Summers, Stuart >; dri-devel@lists.freedesktop.org; Vivi, Rodrigo >; intel-...@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on >i915 >module removal > >On Thu, Dec 12, 2019 at 12:34:49PM -0800, Lucas De Marchi wrote: >>On Thu, Dec 12, 2019 at 09:37:17AM -0800, Matt Roper wrote: >>>On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote: On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote: > On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote: > > On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote: > > >intel_bw_state allocated memory is not getting freed even after > > >module removal. > > > > > >kmemleak reported backtrace: > > > > > > [<79019739>] kmemdup+0x17/0x40 > > > [] intel_bw_duplicate_state+0x1b/0x40 [i915] > > > [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140 > > > [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915] > > > [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915] > > > [ ] drm_atomic_check_only+0x563/0x810 > > > [ ] drm_atomic_commit+0xe/0x50 > > > [ ] drm_atomic_helper_disable_all+0x133/0x160 > > > [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0 > > > [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915] > > > [ ] i915_pci_remove+0x19/0x40 [i915] > > > [<2dcbd148>] pci_device_remove+0x36/0xb0 > > > [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0 > > > [<580e9566>] unbind_store+0xc3/0x120 > > > [<869d0df5>] kernfs_fop_write+0x104/0x190 > > > [<4dc1a355>] vfs_write+0xb9/0x1d0 > > > > what I find strange in this is that the last state was allocated > > by the "driver remove" code path. > > > > > > > >Call the drm_atomic_private_obj_fini(), which inturn calls the > > >intel_bw_destroy_state() to make sure the intel_bw_state memory > > >is freed properly. > > > > > >Signed-off-by: Pankaj Bharadiya > > > > > >--- > > >drivers/gpu/drm/i915/display/intel_bw.c | 5 + > > >drivers/gpu/drm/i915/display/intel_bw.h | 1 + > > >drivers/gpu/drm/i915/display/intel_display.c | 2 ++ > > >3 files changed, 8 insertions(+) > > > > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.c > > >b/drivers/gpu/drm/i915/display/intel_bw.c > > >index dcb66a33be9b..b228671d5a5d 100644 > > >--- a/drivers/gpu/drm/i915/display/intel_bw.c > > >+++ b/drivers/gpu/drm/i915/display/intel_bw.c > > >@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private > > >*dev_priv) > > > > > > return 0; > > >} > > >+ > > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv) { > > >+ drm_atomic_private_obj_fini(_priv->bw_obj); > > >+} > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.h > > >b/drivers/gpu/drm/i915/display/intel_bw.h > > >index 9db10af012f4..20b9ad241802 100644 > > >--- a/drivers/gpu/drm/i915/display/intel_bw.h > > >+++ b/drivers/gpu/drm/i915/display/intel_bw.h > > >@@ -25,6 +25,7 @@ struct intel_bw_state { > > > > > >void intel_bw_init_hw(struct drm_i915_private *dev_priv); int > > >intel_bw_init(struct drm_i915_private *dev_priv); > > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv); > > >int intel_bw_atomic_check(struct intel_atomic_state *state); > > >void intel_bw_crtc_update(struct intel_bw_state *bw_state, > > > const struct intel_crtc_state *crtc_state); > > > diff --git > > >a/drivers/gpu/drm/i915/display/intel_display.c > > >b/drivers/gpu/drm/i915/display/intel_display.c > > >index 3190aa27ffdc..756eb90b1bb1 100644 > > >--- a/drivers/gpu/drm/i915/display/intel_display.c > > >+++ b/drivers/gpu/drm/i915/display/intel_display.c > > >@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct > > >drm_i915_private *i915) > > > > > > intel_gmbus_teardown(i915); > > > > > >+ intel_bw_cleanup(i915); > > > > This doesn't seem to match the (reverse) order of > > intel_modeset_init()... but it's actually the gmbus_teardown() > > that is out of place. Did you check if it's not a wrong shutdown > > ordering? > > > > In intel_modeset_init(), intel_gmbus_setup() happens after > intel_bw_init(). > I think the patch follows the reverse ordering properly. > Am I missing anything? I said it seems that it's the gmbus_teardown() that is
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
Hi Boris. > Just a reminder of my 2 proposals: > > 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can >split your enable/disable logic in 2 parts and make sure things are >ready when the panel/next bridge tries to send DSI commands > 2/ move everything that's needed to send DSI commands out of the >->enable() path (maybe in runtime PM resume/suspend hooks) so you >can call that in the DSI transfer path too > > As pointed out by Laurent, #1 doesn't work because some panel drivers > send DSI commands in their ->prepare() hook, and ->pre_enable() methods > are called in reverse order, meaning that the DRM panel bridge driver > would try to issue DSI commands before the DSI host controllers is ready > to send them. I still thing #2 is a good option. Jitao Shi suggested to extend panels so we had a sequence of: prepare_power() <= new callback, here one should NOT be allowed to send DSI commands prepare() enable() # # panel is now ready to show your favourite christmas movie # disable() unprepare() unprepare_power() <= new callback Would this help implement what you suggest above? Relevant panels would then have to be updated - but this is doable. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] dt-bindings: display: panel: Add binding document for Xinpeng XPP055C272
From: Heiko Stuebner
The XPP055C272 is a 5.5" 720x1280 DSI display.
changes in v4:
- fix id (Maxime)
- drop port (Maxime)
changes in v2:
- add size info into binding title (Sam)
- add more required properties (Sam)
Signed-off-by: Heiko Stuebner
Reviewed-by: Sam Ravnborg
Acked-by: Maxime Ripard
Reviewed-by: Rob Herring
---
.../display/panel/xinpeng,xpp055c272.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
new file mode 100644
index ..378cf9e2549d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xinpeng,xpp055c272.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xinpeng XPP055C272 5.5in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xinpeng,xpp055c272
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi@ff45 {
+panel@0 {
+compatible = "xinpeng,xpp055c272";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vci-supply = <_lcd>;
+};
+};
+
+...
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/3] dt-bindings: Add vendor prefix for Xinpeng Technology
From: Heiko Stuebner Shenzhen Xinpeng Technology Co., Ltd produces for example display panels. Signed-off-by: Heiko Stuebner Acked-by: Sam Ravnborg Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6046f4555852..85e7c26a05c7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1056,6 +1056,8 @@ patternProperties: description: Extreme Engineering Solutions (X-ES) "^xillybus,.*": description: Xillybus Ltd. + "^xinpeng,.*": +description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": description: Xilinx "^xunlong,.*": -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] drm/panel: add panel driver for Xinpeng XPP055C272 panels
From: Heiko Stuebner
Base on the somewhat similar Rocktech driver but adapted for
panel-specific init of the XPP055C272.
changes in v5:
- drop error message when backlight not found, no other panel
does that and if needed it should live in drm_panel_of_backlight
changes in v4:
none
changes in v3:
- remove wrong negative sync flags from display-mode to fix a display
artifact of the output getting move a tiny bit to the right
changes in v2:
- move to drm-panel-internal backlight handling (Sam)
- adapt to changes that happened to drm_panel structs+functions (Sam)
- sort includes (Sam)
- drop unnecessary DRV_NAME constant (Sam)
- do mipi_dsi_dcs_exit_sleep_mode and mipi_dsi_dcs_set_display_on
in panel prepare (not init_sequence) to keep symmetric (Sam)
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xinpeng-xpp055c272.c | 398 ++
3 files changed, 409 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 683ff77a3733..d86d875de783 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -366,4 +366,14 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
help
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+
+config DRM_PANEL_XINPENG_XPP055C272
+ tristate "Xinpeng XPP055C272 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xinpeng
+ XPP055C272 controller for 720x1280 LCD panels with MIPI/RGB/SPI
+ system interfaces.
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8783476110a3..f7cf83672fb8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
new file mode 100644
index ..1645aceab597
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xinpeng xpp055c272 5.5" MIPI-DSI panel driver
+ * Copyright (C) 2019 Theobroma Systems Design und Consulting GmbH
+ *
+ * based on
+ *
+ * Rockteck jh057n00900 5.5" MIPI-DSI panel driver
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define XPP055C272_CMD_ALL_PIXEL_OFF 0x22
+#define XPP055C272_CMD_ALL_PIXEL_ON0x23
+#define XPP055C272_CMD_SETDISP 0xb2
+#define XPP055C272_CMD_SETRGBIF0xb3
+#define XPP055C272_CMD_SETCYC 0xb4
+#define XPP055C272_CMD_SETBGP 0xb5
+#define XPP055C272_CMD_SETVCOM 0xb6
+#define XPP055C272_CMD_SETOTP 0xb7
+#define XPP055C272_CMD_SETPOWER_EXT0xb8
+#define XPP055C272_CMD_SETEXTC 0xb9
+#define XPP055C272_CMD_SETMIPI 0xbA
+#define XPP055C272_CMD_SETVDC 0xbc
+#define XPP055C272_CMD_SETPCR 0xbf
+#define XPP055C272_CMD_SETSCR 0xc0
+#define XPP055C272_CMD_SETPOWER0xc1
+#define XPP055C272_CMD_SETECO 0xc6
+#define XPP055C272_CMD_SETPANEL0xcc
+#define XPP055C272_CMD_SETGAMMA0xe0
+#define XPP055C272_CMD_SETEQ 0xe3
+#define XPP055C272_CMD_SETGIP1 0xe9
+#define XPP055C272_CMD_SETGIP2 0xea
+
+struct xpp055c272 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vci;
+ struct regulator *iovcc;
+ bool prepared;
+};
+
+static inline struct xpp055c272 *panel_to_xpp055c272(struct drm_panel *panel)
+{
+ return container_of(panel, struct xpp055c272, panel);
+}
+
+#define dsi_generic_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xpp055c272_init_sequence(struct xpp055c272 *ctx)
+{
+ struct
[PATCH v4 3/3] drm/panel: add panel driver for Leadtek LTK500HD1829
From: Heiko Stuebner
The LTK500HD1829 is 5.5" DSI display.
changes in v4:
- drop error message if backlight not found, no other panel
does that and if needed it should live in drm_panel_of_backlight
changes in v3:
- drop one more overlooked panel->drm access
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk500hd1829.c| 532 ++
3 files changed, 544 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d86d875de783..41f796b28dd5 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -109,6 +109,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK500HD1829
+ tristate "Leadtek LTK500HD1829 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Kingdisplay kd097d04
+ TFT-LCD modules. The panel has a 1536x2048 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f7cf83672fb8..4dc7acff21b9 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.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_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
new file mode 100644
index ..07494b124301
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -0,0 +1,532 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Theobroma Systems Design und Consulting GmbH
+ *
+ * base on panel-kingdisplay-kd097d04.c
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ltk500hd1829 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vcc;
+ struct regulator *iovcc;
+ bool prepared;
+};
+
+struct ltk500hd1829_cmd {
+ char cmd;
+ char data;
+};
+
+/*
+ * There is no description in the Reference Manual about these commands.
+ * We received them from the vendor, so just use them as is.
+ */
+static const struct ltk500hd1829_cmd init_code[] = {
+ { 0xE0, 0x00 },
+ { 0xE1, 0x93 },
+ { 0xE2, 0x65 },
+ { 0xE3, 0xF8 },
+ { 0x80, 0x03 },
+ { 0xE0, 0x04 },
+ { 0x2D, 0x03 },
+ { 0xE0, 0x01 },
+ { 0x00, 0x00 },
+ { 0x01, 0xB6 },
+ { 0x03, 0x00 },
+ { 0x04, 0xC5 },
+ { 0x17, 0x00 },
+ { 0x18, 0xBF },
+ { 0x19, 0x01 },
+ { 0x1A, 0x00 },
+ { 0x1B, 0xBF },
+ { 0x1C, 0x01 },
+ { 0x1F, 0x7C },
+ { 0x20, 0x26 },
+ { 0x21, 0x26 },
+ { 0x22, 0x4E },
+ { 0x37, 0x09 },
+ { 0x38, 0x04 },
+ { 0x39, 0x08 },
+ { 0x3A, 0x1F },
+ { 0x3B, 0x1F },
+ { 0x3C, 0x78 },
+ { 0x3D, 0xFF },
+ { 0x3E, 0xFF },
+ { 0x3F, 0x00 },
+ { 0x40, 0x04 },
+ { 0x41, 0xA0 },
+ { 0x43, 0x0F },
+ { 0x44, 0x0A },
+ { 0x45, 0x24 },
+ { 0x55, 0x01 },
+ { 0x56, 0x01 },
+ { 0x57, 0xA5 },
+ { 0x58, 0x0A },
+ { 0x59, 0x4A },
+ { 0x5A, 0x38 },
+ { 0x5B, 0x10 },
+ { 0x5C, 0x19 },
+ { 0x5D, 0x7C },
+ { 0x5E, 0x64 },
+ { 0x5F, 0x54 },
+ { 0x60, 0x48 },
+ { 0x61, 0x44 },
+ { 0x62, 0x35 },
+ { 0x63, 0x3A },
+ { 0x64, 0x24 },
+ { 0x65, 0x3B },
+ { 0x66, 0x39 },
+ { 0x67, 0x37 },
+ { 0x68, 0x56 },
+ { 0x69, 0x41 },
+ { 0x6A, 0x47 },
+ { 0x6B, 0x2F },
+ { 0x6C, 0x23 },
+ { 0x6D, 0x13 },
+ { 0x6E, 0x02 },
+ { 0x6F, 0x08 },
+ { 0x70, 0x7C },
+ { 0x71, 0x64 },
+ { 0x72, 0x54 },
+ {
[PATCH v4 2/3] dt-bindings: display: panel: Add binding document for Leadtek LTK500HD1829
From: Heiko Stuebner
The LTK500HD1829 is a 5.0" 720x1280 DSI display.
changes in v2:
- fix id (Maxime)
- drop port (Maxime)
Signed-off-by: Heiko Stuebner
Acked-by: Maxime Ripard
---
.../display/panel/leadtek,ltk500hd1829.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
new file mode 100644
index ..123869533a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk500hd1829.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK500HD1829 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: leadtek,ltk500hd1829
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vcc-supply:
+ description: regulator that supplies the vcc voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi@ff45 {
+panel@0 {
+compatible = "leadtek,ltk500hd1829";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vcc-supply = <_2v8>;
+};
+};
+
+...
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] dt-bindings: Add vendor prefix for Leadtek Technology
From: Heiko Stuebner Shenzhen Leadtek Technology Co., Ltd. produces for example display and touch panels. Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 85e7c26a05c7..4e6248ec5ed9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -513,6 +513,8 @@ patternProperties: description: Lantiq Semiconductor "^lattice,.*": description: Lattice Semiconductor + "^leadtek,.*": +description: Shenzhen Leadtek Technology Co., Ltd. "^leez,.*": description: Leez "^lego,.*": -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] iommu: allow the dma-iommu api to use bounce buffers
Hi Tom,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on rockchip/for-next]
[cannot apply to iommu/next tegra/for-next vfio/next linus/master v5.5-rc3
next-20191219]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Tom-Murphy/Convert-the-intel-iommu-driver-to-the-dma-iommu-api/20191224-171249
base:
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
for-next
config: x86_64-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers//iommu/dma-iommu.c: In function '__iommu_dma_map':
>> drivers//iommu/dma-iommu.c:568:3: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
void *padding_start = phys_to_virt(phys);
^~~~
vim +568 drivers//iommu/dma-iommu.c
537
538 static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
539 size_t org_size, dma_addr_t dma_mask, bool coherent,
540 enum dma_data_direction dir, unsigned long attrs)
541 {
542 int prot = dma_info_to_prot(dir, coherent, attrs);
543 struct iommu_domain *domain = iommu_get_dma_domain(dev);
544 struct iommu_dma_cookie *cookie = domain->iova_cookie;
545 struct iova_domain *iovad = >iovad;
546 size_t iova_off = iova_offset(iovad, phys);
547 size_t aligned_size = iova_align(iovad, org_size + iova_off);
548 dma_addr_t iova;
549
550 if (unlikely(iommu_dma_deferred_attach(dev, domain)))
551 return DMA_MAPPING_ERROR;
552
553 #ifdef CONFIG_SWIOTLB
554 /*
555 * If both the physical buffer start address and size are
556 * page aligned, we don't need to use a bounce page.
557 */
558 if (iommu_needs_bounce_buffer(dev)
559 && !iova_offset(iovad, phys | org_size)) {
560 phys = swiotlb_tbl_map_single(dev,
561 __phys_to_dma(dev, io_tlb_start),
562 phys, org_size, aligned_size, dir,
attrs);
563
564 if (phys == DMA_MAPPING_ERROR)
565 return DMA_MAPPING_ERROR;
566
567 /* Cleanup the padding area. */
> 568 void *padding_start = phys_to_virt(phys);
569 size_t padding_size = aligned_size;
570
571 if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
572 (dir == DMA_TO_DEVICE ||
573 dir == DMA_BIDIRECTIONAL)) {
574 padding_start += org_size;
575 padding_size -= org_size;
576 }
577
578 memset(padding_start, 0, padding_size);
579 }
580 #endif
581
582 iova = iommu_dma_alloc_iova(domain, aligned_size, dma_mask,
dev);
583 if (!iova)
584 return DMA_MAPPING_ERROR;
585
586 if (iommu_map_atomic(domain, iova, phys - iova_off,
aligned_size,
587 prot)) {
588
589 if (unlikely(is_swiotlb_buffer(phys)))
590 swiotlb_tbl_unmap_single(dev, phys,
aligned_size,
591 aligned_size, dir, attrs);
592 iommu_dma_free_iova(cookie, iova, aligned_size, NULL);
593 return DMA_MAPPING_ERROR;
594 }
595 return iova + iova_off;
596 }
597
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
On Tue, 24 Dec 2019 10:49:36 +0100 Boris Brezillon wrote: > On Tue, 24 Dec 2019 10:44:22 +0100 > Boris Brezillon wrote: > > > On Tue, 24 Dec 2019 10:16:49 +0100 > > Andrzej Hajda wrote: > > > > > On 23.12.2019 10:55, Marek Szyprowski wrote: > > > > Hi Boris, > > > > > > > > On 16.12.2019 16:25, Boris Brezillon wrote: > > > >> On Mon, 16 Dec 2019 16:02:36 +0100 > > > >> Marek Szyprowski wrote: > > > >>> Hi Boris, > > > >>> > > > >>> On 16.12.2019 15:55, Boris Brezillon wrote: > > > On Mon, 16 Dec 2019 14:54:25 +0100 > > > Marek Szyprowski wrote: > > > > On 03.12.2019 15:15, Boris Brezillon wrote: > > > >> So that each element in the chain can easily access its > > > >> predecessor. > > > >> This will be needed to support bus format negotiation between > > > >> elements > > > >> of the bridge chain. > > > >> > > > >> Signed-off-by: Boris Brezillon > > > >> Reviewed-by: Neil Armstrong > > > >> Reviewed-by: Laurent Pinchart > > > >> > > > > I've noticed that this patch got merged to linux-next as commit > > > > 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of > > > > Samsung Exynos5250-based Arndale board. Booting stops after > > > > following > > > > messages: > > > > > > > > [drm] Exynos DRM: using 1440.fimd device for DMA mapping > > > > operations > > > > exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) > > > > exynos-drm exynos-drm: bound 1445.mixer (ops > > > > mixer_component_ops) > > > > exynos-drm exynos-drm: bound 1450.dsi (ops > > > > exynos_dsi_component_ops) > > > > exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_component_ops) > > > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > > [drm] No driver support for vblank timestamp query. > > > > [drm] Cannot find any crtc or sizes > > > > [drm] Cannot find any crtc or sizes > > > > [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0 > > > > > > > > I will try to debug this and provide more information soon. > > > > > > > Can you try with this diff applied? > > > >>> This patch doesn't change anything. > > > >> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain > > > >> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and > > > >> after the list_splice_init() call? > > > > encoder->bridge_chain contains only one element. dsi->drive_chain is > > > > empty. > > > > > > > > Replacing that list_splice() with > > > > INIT_LIST_HEAD(>bridge_chain) > > > > fixed the boot issue. > > > > If INIT_LIST_HEAD() worked, I don't understand why replacing the > > list_splice() call by a list_splice_init() (which doing a list_splice() > > + INIT_LIST_HEAD()) didn't fix the problem. Are you sure the > > list_splice_init() version doesn't work? > > > > > > It looks that this is related with the way the > > > > Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej > > > > will give a bit more detailed comment and spread some light on this. > > > > > > > > > > > > > Hi Marek, Boris, > > > > > > > > > I have not followed latest patches due to high work load, my bad. Marek > > > thanks from pointing > > > > > > About ExynosDSI bridge handling: > > > > > > The order of calling encoder, bridge (and consequently panel) ops > > > enforced by DRM core (bridge->pre_enable, encoder->enable, > > > bridge->enable) does not fit to ExynosDSI hardware initialization > > > sequence, if I remember correctly it does not fit to whole MIPI DSI > > > standard (I think similar situation is with eDP). As a result DSI > > > drivers must use some ugly workarounds, rely on HW properly coping with > > > incorrect sequences, or, as in case of ExynosDSI driver, just avoid > > > using encoder->bridge chaining and call bridge ops by itself when > > > suitable. > > > > Yes, that's definitely hack-ish, and I proposed 2 solutions to address > > that in previous versions of this patchset, unfortunately I didn't get > > any feedback so I went for the less invasive option (keep the hack but > > adapt it to the double-linked list changes), which still lead to > > regressions :-/. > > > > Just a reminder of my 2 proposals: > > > > 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can > >split your enable/disable logic in 2 parts and make sure things are > >ready when the panel/next bridge tries to send DSI commands > > 2/ move everything that's needed to send DSI commands out of the > >->enable() path (maybe in runtime PM resume/suspend hooks) so you > >can call that in the DSI transfer path too > > > > As pointed out by Laurent, #1 doesn't work because some panel drivers > > send DSI commands in their ->prepare() hook, and ->pre_enable() methods > > are called in
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
On Tue, 24 Dec 2019 10:44:22 +0100 Boris Brezillon wrote: > On Tue, 24 Dec 2019 10:16:49 +0100 > Andrzej Hajda wrote: > > > On 23.12.2019 10:55, Marek Szyprowski wrote: > > > Hi Boris, > > > > > > On 16.12.2019 16:25, Boris Brezillon wrote: > > >> On Mon, 16 Dec 2019 16:02:36 +0100 > > >> Marek Szyprowski wrote: > > >>> Hi Boris, > > >>> > > >>> On 16.12.2019 15:55, Boris Brezillon wrote: > > On Mon, 16 Dec 2019 14:54:25 +0100 > > Marek Szyprowski wrote: > > > On 03.12.2019 15:15, Boris Brezillon wrote: > > >> So that each element in the chain can easily access its predecessor. > > >> This will be needed to support bus format negotiation between > > >> elements > > >> of the bridge chain. > > >> > > >> Signed-off-by: Boris Brezillon > > >> Reviewed-by: Neil Armstrong > > >> Reviewed-by: Laurent Pinchart > > > I've noticed that this patch got merged to linux-next as commit > > > 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of > > > Samsung Exynos5250-based Arndale board. Booting stops after following > > > messages: > > > > > > [drm] Exynos DRM: using 1440.fimd device for DMA mapping > > > operations > > > exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) > > > exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops) > > > exynos-drm exynos-drm: bound 1450.dsi (ops > > > exynos_dsi_component_ops) > > > exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_component_ops) > > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [drm] No driver support for vblank timestamp query. > > > [drm] Cannot find any crtc or sizes > > > [drm] Cannot find any crtc or sizes > > > [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0 > > > > > > I will try to debug this and provide more information soon. > > > > > Can you try with this diff applied? > > >>> This patch doesn't change anything. > > >> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain > > >> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and > > >> after the list_splice_init() call? > > > encoder->bridge_chain contains only one element. dsi->drive_chain is > > > empty. > > > > > > Replacing that list_splice() with INIT_LIST_HEAD(>bridge_chain) > > > fixed the boot issue. > > If INIT_LIST_HEAD() worked, I don't understand why replacing the > list_splice() call by a list_splice_init() (which doing a list_splice() > + INIT_LIST_HEAD()) didn't fix the problem. Are you sure the > list_splice_init() version doesn't work? > > > > It looks that this is related with the way the > > > Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej > > > will give a bit more detailed comment and spread some light on this. > > > > > > Hi Marek, Boris, > > > > > > I have not followed latest patches due to high work load, my bad. Marek > > thanks from pointing > > > > About ExynosDSI bridge handling: > > > > The order of calling encoder, bridge (and consequently panel) ops > > enforced by DRM core (bridge->pre_enable, encoder->enable, > > bridge->enable) does not fit to ExynosDSI hardware initialization > > sequence, if I remember correctly it does not fit to whole MIPI DSI > > standard (I think similar situation is with eDP). As a result DSI > > drivers must use some ugly workarounds, rely on HW properly coping with > > incorrect sequences, or, as in case of ExynosDSI driver, just avoid > > using encoder->bridge chaining and call bridge ops by itself when suitable. > > > > Yes, that's definitely hack-ish, and I proposed 2 solutions to address > that in previous versions of this patchset, unfortunately I didn't get > any feedback so I went for the less invasive option (keep the hack but > adapt it to the double-linked list changes), which still lead to > regressions :-/. > > Just a reminder of my 2 proposals: > > 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can >split your enable/disable logic in 2 parts and make sure things are >ready when the panel/next bridge tries to send DSI commands > 2/ move everything that's needed to send DSI commands out of the >->enable() path (maybe in runtime PM resume/suspend hooks) so you >can call that in the DSI transfer path too > > As pointed out by Laurent, #1 doesn't work because some panel drivers > send DSI commands in their ->prepare() hook, and ->pre_enable() methods > are called in reverse order, meaning that the DRM panel bridge driver > would try to issue DSI commands before the DSI host controllers is ready > to send them. I still thing #2 is a good option. > > > > > So proper patch converting to double-linked list should not try to > > splice ExynosDSI private bridge list with with encoder's, encoder's list > > should be always empty, as Marek
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
On Tue, 24 Dec 2019 10:16:49 +0100 Andrzej Hajda wrote: > On 23.12.2019 10:55, Marek Szyprowski wrote: > > Hi Boris, > > > > On 16.12.2019 16:25, Boris Brezillon wrote: > >> On Mon, 16 Dec 2019 16:02:36 +0100 > >> Marek Szyprowski wrote: > >>> Hi Boris, > >>> > >>> On 16.12.2019 15:55, Boris Brezillon wrote: > On Mon, 16 Dec 2019 14:54:25 +0100 > Marek Szyprowski wrote: > > On 03.12.2019 15:15, Boris Brezillon wrote: > >> So that each element in the chain can easily access its predecessor. > >> This will be needed to support bus format negotiation between elements > >> of the bridge chain. > >> > >> Signed-off-by: Boris Brezillon > >> Reviewed-by: Neil Armstrong > >> Reviewed-by: Laurent Pinchart > > I've noticed that this patch got merged to linux-next as commit > > 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of > > Samsung Exynos5250-based Arndale board. Booting stops after following > > messages: > > > > [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations > > exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) > > exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops) > > exynos-drm exynos-drm: bound 1450.dsi (ops exynos_dsi_component_ops) > > exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_component_ops) > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [drm] No driver support for vblank timestamp query. > > [drm] Cannot find any crtc or sizes > > [drm] Cannot find any crtc or sizes > > [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0 > > > > I will try to debug this and provide more information soon. > > > Can you try with this diff applied? > >>> This patch doesn't change anything. > >> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain > >> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and > >> after the list_splice_init() call? > > encoder->bridge_chain contains only one element. dsi->drive_chain is empty. > > > > Replacing that list_splice() with INIT_LIST_HEAD(>bridge_chain) > > fixed the boot issue. If INIT_LIST_HEAD() worked, I don't understand why replacing the list_splice() call by a list_splice_init() (which doing a list_splice() + INIT_LIST_HEAD()) didn't fix the problem. Are you sure the list_splice_init() version doesn't work? > > It looks that this is related with the way the > > Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej > > will give a bit more detailed comment and spread some light on this. > > > Hi Marek, Boris, > > > I have not followed latest patches due to high work load, my bad. Marek > thanks from pointing > > About ExynosDSI bridge handling: > > The order of calling encoder, bridge (and consequently panel) ops > enforced by DRM core (bridge->pre_enable, encoder->enable, > bridge->enable) does not fit to ExynosDSI hardware initialization > sequence, if I remember correctly it does not fit to whole MIPI DSI > standard (I think similar situation is with eDP). As a result DSI > drivers must use some ugly workarounds, rely on HW properly coping with > incorrect sequences, or, as in case of ExynosDSI driver, just avoid > using encoder->bridge chaining and call bridge ops by itself when suitable. Yes, that's definitely hack-ish, and I proposed 2 solutions to address that in previous versions of this patchset, unfortunately I didn't get any feedback so I went for the less invasive option (keep the hack but adapt it to the double-linked list changes), which still lead to regressions :-/. Just a reminder of my 2 proposals: 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can split your enable/disable logic in 2 parts and make sure things are ready when the panel/next bridge tries to send DSI commands 2/ move everything that's needed to send DSI commands out of the ->enable() path (maybe in runtime PM resume/suspend hooks) so you can call that in the DSI transfer path too As pointed out by Laurent, #1 doesn't work because some panel drivers send DSI commands in their ->prepare() hook, and ->pre_enable() methods are called in reverse order, meaning that the DRM panel bridge driver would try to issue DSI commands before the DSI host controllers is ready to send them. I still thing #2 is a good option. > > So proper patch converting to double-linked list should not try to > splice ExynosDSI private bridge list with with encoder's, encoder's list > should be always empty, as Marek suggested. That's exactly what I wanted to do: make the encoder's list empty after attach() and restore it to its initial state before unregistering the bridge, except I forgot that list_splice() doesn't call INIT_LIST_HEAD(). It's still not clear to me why replacing the list_splice() call by a list_splice_init() didn't work. Also note
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
On 23.12.2019 10:55, Marek Szyprowski wrote:
> Hi Boris,
>
> On 16.12.2019 16:25, Boris Brezillon wrote:
>> On Mon, 16 Dec 2019 16:02:36 +0100
>> Marek Szyprowski wrote:
>>> Hi Boris,
>>>
>>> On 16.12.2019 15:55, Boris Brezillon wrote:
On Mon, 16 Dec 2019 14:54:25 +0100
Marek Szyprowski wrote:
> On 03.12.2019 15:15, Boris Brezillon wrote:
>> So that each element in the chain can easily access its predecessor.
>> This will be needed to support bus format negotiation between elements
>> of the bridge chain.
>>
>> Signed-off-by: Boris Brezillon
>> Reviewed-by: Neil Armstrong
>> Reviewed-by: Laurent Pinchart
> I've noticed that this patch got merged to linux-next as commit
> 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting of
> Samsung Exynos5250-based Arndale board. Booting stops after following
> messages:
>
> [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
> exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
> exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops)
> exynos-drm exynos-drm: bound 1450.dsi (ops exynos_dsi_component_ops)
> exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_component_ops)
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> [drm] Cannot find any crtc or sizes
> [drm] Cannot find any crtc or sizes
> [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0
>
> I will try to debug this and provide more information soon.
>
Can you try with this diff applied?
>>> This patch doesn't change anything.
>> Okay. Can you do a list_for_each_entry() on both encoder->bridge_chain
>> and dsi->bridge_chain (dump bridge pointers in a pr_info()) before and
>> after the list_splice_init() call?
> encoder->bridge_chain contains only one element. dsi->drive_chain is empty.
>
> Replacing that list_splice() with INIT_LIST_HEAD(>bridge_chain)
> fixed the boot issue. It looks that this is related with the way the
> Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej
> will give a bit more detailed comment and spread some light on this.
Hi Marek, Boris,
I have not followed latest patches due to high work load, my bad. Marek
thanks from pointing
About ExynosDSI bridge handling:
The order of calling encoder, bridge (and consequently panel) ops
enforced by DRM core (bridge->pre_enable, encoder->enable,
bridge->enable) does not fit to ExynosDSI hardware initialization
sequence, if I remember correctly it does not fit to whole MIPI DSI
standard (I think similar situation is with eDP). As a result DSI
drivers must use some ugly workarounds, rely on HW properly coping with
incorrect sequences, or, as in case of ExynosDSI driver, just avoid
using encoder->bridge chaining and call bridge ops by itself when suitable.
So proper patch converting to double-linked list should not try to
splice ExynosDSI private bridge list with with encoder's, encoder's list
should be always empty, as Marek suggested.
Regards
Andrzej
>
> I can send a formal patch fixing this if You want.
>
--->8---
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 3955f84dc893..118ecedc7621 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1523,7 +1523,7 @@ static int exynos_dsi_host_attach(struct
mipi_dsi_host *host,
if (out_bridge) {
drm_bridge_attach(encoder, out_bridge, NULL);
dsi->out_bridge = out_bridge;
- list_splice(>bridge_chain, >bridge_chain);
+ list_splice_init(>bridge_chain,
>bridge_chain);
} else {
int ret = exynos_dsi_create_connector(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 6c5b80ad6154..e1378d48210f 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1613,7 +1613,7 @@ static int vc4_dsi_bind(struct device *dev, struct
device *master, void *data)
* from our driver, since we need to sequence them within the
* encoder's enable/disable paths.
*/
- list_splice(>encoder->bridge_chain, >bridge_chain);
+ list_splice_init(>encoder->bridge_chain, >bridge_chain);
if (dsi->port == 0)
vc4_debugfs_add_regset32(drm, "dsi0_regs", >regset);
@@ -1639,7 +1639,7 @@ static void vc4_dsi_unbind(struct device *dev,
struct device *master,
* Restore the bridge_chain so the bridge detach procedure can
happen
* normally.
*/
- list_splice(>bridge_chain,
