Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, Aug 26, 2020 at 8:43 PM Kees Cook wrote: > > On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote: > > On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote: > > > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley > > > wrote: > > > > > > > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote: > > > > > > [...] > > > > > > > > Since both threads seem to have petered out, let me suggest in > > > > > > > > kernel.h: > > > > > > > > > > > > > > > > #define cast_out(ptr, container, member) \ > > > > > > > > container_of(ptr, typeof(*container), member) > > > > > > > > > > > > > > > > It does what you want, the argument order is the same as > > > > > > > > container_of with the only difference being you name the > > > > > > > > containing structure instead of having to specify its type. > > > > > > > > > > > > > > Not to incessantly bike shed on the naming, but I don't like > > > > > > > cast_out, it's not very descriptive. And it has connotations of > > > > > > > getting rid of something, which isn't really true. > > > > > > > > > > > > Um, I thought it was exactly descriptive: you're casting to the > > > > > > outer container. I thought about following the C++ dynamic casting > > > > > > style, so out_cast(), but that seemed a bit pejorative. What about > > > > > > outer_cast()? > > > > > > > > > > > > > FWIW, I like the from_ part of the original naming, as it has > > > > > > > some clues as to what is being done here. Why not just > > > > > > > from_container()? That should immediately tell people what it > > > > > > > does without having to look up the implementation, even before > > > > > > > this becomes a part of the accepted coding norm. > > > > > > > > > > > > I'm not opposed to container_from() but it seems a little less > > > > > > descriptive than outer_cast() but I don't really care. I always > > > > > > have to look up container_of() when I'm using it so this would just > > > > > > be another macro of that type ... > > > > > > > > > > > > > > > > So far we have a few which have been suggested as replacement > > > > > for from_tasklet() > > > > > > > > > > - out_cast() or outer_cast() > > > > > - from_member(). > > > > > - container_from() or from_container() > > > > > > > > > > from_container() sounds fine, would trimming it a bit work? like > > > > > from_cont(). > > > > > > > > I'm fine with container_from(). It's the same form as container_of() > > > > and I think we need urgent agreement to not stall everything else so > > > > the most innocuous name is likely to get the widest acceptance. > > > > > > Kees, > > > > > > Will you be sending the newly proposed API to Linus? I have V2 > > > which uses container_from() > > > ready to be sent out. > > > > I liked that James swapped the first two arguments so that it matches > > container_of(). Plus it's nice that when you have: > > > > struct whatever *foo = container_from(ptr, foo, member); > > > > Then it means that "ptr == &foo->member". > > I'm a bit stalled right now -- the merge window was keeping me busy, and > this week is the Linux Plumbers Conference. This is on my list, but I > haven't gotten back around to it. If you want, feel free to send the > container_from() patch; you might be able to unblock this faster than me > right now. :) > Sure, Thanks. -- - Allen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
Hi Ville,
> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> wrote:
>
> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
>> LSPCON only supports 8 bpc for RGB/YCbCr444.
>>
>> Set the correct bpp otherwise it renders blank screen.
>
> Hmm. Does
> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> work?
>
> Actually better make that dp_downstream_ports_5^^^ aka.
> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> converters") to avoid the experiments and hacks I have sitting on top.
Can you please rebase it to mainline master or drm-tip?
I am getting errors on the branch:
DESCEND objtool
CALLscripts/atomic/check-atomics.sh
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
Building modules, stage 2.
MODPOST 166 modules
LD arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
`__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first defined
here
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
make[2]: *** [arch/x86/boot/compressed/Makefile:119:
arch/x86/boot/compressed/vmlinux] Error 1
make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
Error 2
make: *** [arch/x86/Makefile:284: bzImage] Error 2
make: *** Waiting for unfinished jobs
Kai-Heng
>
>>
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> index b781bf469644..c7a44fcaade8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
>> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
>> *connector,
>> crtc_state->port_clock /= 2;
>> crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>> crtc_state->lspcon_downsampling = true;
>> -}
>> +} else
>> +crtc_state->pipe_bpp = 24;
>> }
>>
>> static bool lspcon_probe(struct intel_lspcon *lspcon)
>> --
>> 2.17.1
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index df9338257ae0..2476e40c67ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2834,12 +2834,18 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
&dm_atomic_state_funcs);
r = amdgpu_display_modeset_create_props(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
r = amdgpu_dm_audio_init(adev);
- if (r)
+ if (r) {
+ dc_release_state(state->context);
+ kfree(state);
return r;
+ }
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/2] i2c: i2c-qcom-geni: Store DMA mapping data in geni_i2c_dev struct
Hi Roja,
On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:
Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping
data scope. For example during shutdown callback to unmap DMA mapping,
this stored DMA mapping data can be used to call geni_se_tx_dma_unprep
and geni_se_rx_dma_unprep functions.
Signed-off-by: Roja Rani Yarubandi
---
Changes in V2:
- As per Stephen's comments, changed commit text, fixed minor nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 7f130829bf01..1fda5c7c2cfc 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -86,6 +86,9 @@ struct geni_i2c_dev {
u32 clk_freq_out;
const struct geni_i2c_clk_fld *clk_fld;
int suspended;
+ dma_addr_t tx_dma;
+ dma_addr_t rx_dma;
+ size_t xfer_len;
};
struct geni_i2c_err_log {
@@ -358,6 +361,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = msg->len;
nit: gi2c->xfer = len, for tx_one_msg as well.
Regards,
Akash
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -384,6 +388,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
+ gi2c->rx_dma = rx_dma;
geni_se_rx_dma_unprep(se, rx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
@@ -400,6 +405,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
+ gi2c->xfer_len = msg->len;
if (!of_machine_is_compatible("lenovo,yoga-c630"))
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
@@ -429,6 +435,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
if (dma_buf) {
if (gi2c->err)
geni_i2c_tx_fsm_rst(gi2c);
+ gi2c->tx_dma = tx_dma;
geni_se_tx_dma_unprep(se, tx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] dyndbg: POC use dynamic_debug_exec_queries in DRM
This patchset tests/demonstrates using dynamic_debug_exec_queries() to alter 2 drivers' pr_debugs without a user directly using >control. For drm.core, I copied drm.debug module parameter model, adding drm.debug2 as a POC user interface to control 2 pr_debug additions to drm_printk:drm_dbg,dev_dbg, allowing both category and >control to work in parallel. This patch makes no attempt to integrate drm's category mechanism with the "format=^class" callsite selection; thats the "theory", but it needs testing. For i915/gvt, I repeated the pattern. I focussed on gvt only, because it had the most compelling use of format strings as pr_debug classes; ~120 pr_debugs in 9 classes. These are mapped onto bits of the param. bash-5.0# echo 0x0 > /sys/module/i915/parameters/debug_dyn [ 3137.044185] set_dyndbg: result:0x0 from 0x0 [ 3137.044185] [ 3137.047370] dyndbg: query 0: "format='^gvt: cmd: ' -p" [ 3137.050302] dyndbg: entry, buf:'format='^gvt: cmd: ' -p' [ 3137.053331] dyndbg: start-of-word:0 'format='^gvt: cmd: ' -p' These patches were the test/use case for-59 fixes: https://lore.kernel.org/lkml/20200825173339.2082585-1-jim.cro...@gmail.com/ Jim Cromie (4): drm-printk: POC caller of dynamic-debug-exec-queries drm-printk: call pr_debug() from drm_dev_dbg, __drm_dbg i915: add -DDYNAMIC_DEBUG_MODULE to i915/gvt/Makefile i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt drivers/gpu/drm/drm_print.c| 54 ++--- drivers/gpu/drm/i915/gvt/Makefile | 5 +- drivers/gpu/drm/i915/i915_params.c | 76 ++ 3 files changed, 127 insertions(+), 8 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option.
Hi All, On Mon, 24 Aug 2020 19:51:55 +0500 Bilal Wasim wrote: > fbcon doc mentions FRAMEBUFFER_CONSOLE option to be under > Device Drivers->Graphics Support->Frame buffer Devices-> > Console display driver support->Framebuffer Console Support, > while its under Device Drivers->Graphics Support-> > Console display driver support->Framebuffer Console Support. > > Correcting it in the docs. > > Signed-off-by: Bilal Wasim > --- > Documentation/fb/fbcon.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst > index e57a3d1d085a..a7b487cba307 100644 > --- a/Documentation/fb/fbcon.rst > +++ b/Documentation/fb/fbcon.rst > @@ -20,8 +20,8 @@ A. Configuration > > > The framebuffer console can be enabled by using your favorite kernel > -configuration tool. It is under Device Drivers->Graphics > Support->Frame -buffer Devices->Console display driver > support->Framebuffer Console Support. +configuration tool. It is > under Device Drivers->Graphics Support-> +Console display driver > support->Framebuffer Console Support. Select 'y' to compile support > statically or 'm' for module support. The module will be fbcon. > Can this simple patch be merged? -Bilal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ingenic: Fix driver not probing when IPU port is missing
Even if support for the IPU was compiled in, we may run on a device
(e.g. the Qi LB60) where the IPU is not available, or simply with an old
devicetree without the IPU node. In that case the ingenic-drm refused to
probe.
Fix the driver so that it will probe even if the IPU node is not present
in devicetree (but then IPU support is disabled of course).
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ada990a7f911..216b67f1672e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -673,6 +673,18 @@ static void ingenic_drm_unbind_all(void *d)
component_unbind_all(priv->dev, &priv->drm);
}
+static inline struct device_node *ingenic_drm_get_ipu_node(struct device *dev)
+{
+ /* IPU is at port address 8 */
+ return of_graph_get_remote_node(dev->of_node, 8, 0);
+}
+
+static inline bool ingenic_drm_has_ipu(struct device *dev)
+{
+ return IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
+ !!ingenic_drm_get_ipu_node(dev);
+}
+
static int ingenic_drm_bind(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -808,7 +820,7 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
- if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
+ if (ingenic_drm_has_ipu(dev)) {
ret = component_bind_all(dev, drm);
if (ret) {
if (ret != -EPROBE_DEFER)
@@ -970,12 +982,9 @@ static int ingenic_drm_probe(struct platform_device *pdev)
if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
return ingenic_drm_bind(dev);
- /* IPU is at port address 8 */
- np = of_graph_get_remote_node(dev->of_node, 8, 0);
- if (!np) {
- dev_err(dev, "Unable to get IPU node\n");
- return -EINVAL;
- }
+ np = ingenic_drm_get_ipu_node(dev);
+ if (!np)
+ return ingenic_drm_bind(dev);
drm_of_component_match_add(dev, &match, compare_of, np);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 0/2] Convert mtk-dpi to drm_bridge API
The mtk-dpi driver still uses the drm_encoder API which is now somewhat deprecated. We started to move all the Mediatek drivers to the drm_bridge API, like we did for the mtk-dsi driver [1], this is another small step to be able to fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver. [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559 Changes in v2: - Maintain error message when attach to bridge fails. (Boris) Enric Balletbo i Serra (2): drm/mediatek: mtk_dpi: Rename bridge to next_bridge drm/mediatek: mtk_dpi: Convert to bridge driver drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +- 1 file changed, 45 insertions(+), 32 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/49] DRM driver for Hikey 970
Le mardi 25 août 2020 à 13:30 +0200, Mauro Carvalho Chehab a écrit : > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > wrote: > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote: > > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab > > > > > > > wrote: > > > > > > > > This patch series port the out-of-tree driver for Hikey 970 > > > > > > > > (which > > > > > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > > > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > > > > > > > > > Based on his history, this driver seems to be originally written > > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > > > > > implementation for FB dev API. > > > > > > > > > > > > > > > > As I need to preserve the original history (with has patches > > > > > > > > from > > > > > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > > > > > patch applied there. The remaining patches are incremental, > > > > > > > > and port this driver to work with upstream Kernel. > > > > > > > > > > > > > ... > > > > > > > > - Due to legal reasons, I need to preserve the authorship of > > > > > > > > each one responsbile for each patch. So, I need to start from > > > > > > > > the original patch from Kernel 4.4; > > > > > ... > > > > > > > I do acknowledge you need to preserve history and all - > > > > > > > but this patchset is not easy to review. > > > > > > > > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by > > > > > > and > > > > > > Co-developed-by should be enough, shouldn't it ? Having a public > > > > > > branch > > > > > > that contains the history is useful if anyone is interested, but I > > > > > > don't > > > > > > think it's required in mainline. > > > > > > > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > > > > > have on this but preserving the "absolute" history here is actively > > > > > detrimental for review and understanding of the patch set. > > > > > > > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > > > > > lines should be sufficient to provide both atribution credit and DCO > > > > > history. > > > > > > > > I'm not convinced that, from legal standpoint, folding things would > > > > be enough. See, there are at least 3 legal systems involved here > > > > among the different patch authors: > > > > > > > > - civil law; > > > > - common law; > > > > - customary law + common law. > > > > > > > > Merging stuff altogether from different law systems can be problematic, > > > > and trying to discuss this with experienced IP property lawyers will > > > > for sure take a lot of time and efforts. I also bet that different > > > > lawyers will have different opinions, because laws are subject to > > > > interpretation. With that matter I'm not aware of any court rules > > > > with regards to folded patches. So, it sounds to me that folding > > > > patches is something that has yet to be proofed in courts around > > > > the globe. > > > > > > > > At least for US legal system, it sounds that the Country of > > > > origin of a patch is relevant, as they have a concept of > > > > "national technology" that can be subject to export regulations. > > > > > > > > From my side, I really prefer to play safe and stay out of any such > > > > legal discussions. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-) Regardless of the "re
Re: [PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors
On Wed, 26 Aug 2020 10:15:22 +0200 Enric Balletbo i Serra wrote: > In an eDP application, HPD is not required and on most bridge chips > useless. If HPD is not used, we need to set initial status as > connected, otherwise the connector created by the > drm_bridge_connector API remains in an unknown state. > > Reviewed-by: Laurent Pinchart > Acked-by: Sam Ravnborg > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v2: > - Included the patch `drm/bridge_connector: Set default status > connected for eDP connectors` > > drivers/gpu/drm/drm_bridge_connector.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c > b/drivers/gpu/drm/drm_bridge_connector.c index > c6994fe673f3..a58cbde59c34 100644 --- > a/drivers/gpu/drm/drm_bridge_connector.c +++ > b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@ > drm_bridge_connector_detect(struct drm_connector *connector, bool > force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS: > case DRM_MODE_CONNECTOR_DSI: > + case DRM_MODE_CONNECTOR_eDP: > status = connector_status_connected; > break; > default: Reviewed-by: Bilal Wasim Tested-by: Bilal Wasim -Bilal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling
On Wed, 26 Aug 2020 10:15:26 +0200
Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> -> ps8640_bridge_get_edid
>
> Actually if the bridge pre_enable() function was not called before
> get_edid(), the driver will not be able to get the EDID properly and
> display will not work until a second get_edid() call is issued and if
> pre_enable() is called before. The side effect of this, for example,
> is that you see anything when `Frecon` starts, neither the splash
> screen, until the graphical session manager starts.
>
> To fix this we need to make sure that all we need is enabled before
> reading the EDID. This means the following:
>
> 1. If get_edid() is called before having the device powered we need to
>power on the device. In such case, the driver will power off again
> the device.
>
> 2. If get_edid() is called after having the device powered, all should
>just work. We added a powered flag in order to avoid recurrent
> calls to ps8640_bridge_poweron() and unneeded delays.
>
> 3. This seems to be specific for this device, but we need to make sure
>the panel is powered on before do a power on cycle on this device.
>Otherwise the device fails to retrieve the EDID.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam
> Ravnborg)
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 64
> +++--- 1 file changed, 58 insertions(+), 6
> deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> 9f7b7a9c53c5..c5d76e209bda 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -65,6 +65,7 @@ struct
> ps8640 { struct regulator_bulk_data supplies[2];
> struct gpio_desc *gpio_reset;
> struct gpio_desc *gpio_powerdown;
> + bool powered;
> };
>
> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct
> ps8640 *ps_bridge, return 0;
> }
>
> -static void ps8640_pre_enable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
> unsigned long timeout;
> int ret, status;
>
> + if (ps_bridge->powered)
> + return;
> +
> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
> ps_bridge->supplies);
> if (ret < 0) {
> @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) goto err_regulators_disable;
> }
>
> + ps_bridge->powered = true;
> +
> return;
>
> err_regulators_disable:
> @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) ps_bridge->supplies);
> }
>
> -static void ps8640_post_disable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> int ret;
>
> - ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (!ps_bridge->powered)
> + return;
>
> gpiod_set_value(ps_bridge->gpio_reset, 1);
> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
> @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct
> drm_bridge *bridge) ps_bridge->supplies);
> if (ret < 0)
> DRM_ERROR("cannot disable regulators %d\n", ret);
> +
> + ps_bridge->powered = false;
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + int ret;
> +
> + ps8640_bridge_poweron(ps_bridge);
> +
> + ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (ret < 0)
> + ps8640_bridge_poweroff(ps_bridge);
> +}
> +
> +static void ps8640_post_disable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + ps8640_bridge_poweroff(ps_bridge);
> }
>
> static int ps8640_bridge_attach(struct drm_bridge *bridge,
> @@ -249,9 +276,34 @@ static struct edid
> *ps8640_bridge_get_edid(struct drm_bridge *bridge, struct
> drm_connector *connector) {
> struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + bool poweroff = !ps_bridge->powered;
> + struct edid *edid;
> +
> + /*
> + * When we end calling get_edid() triggered by an ioctl, i.e
> + *
> + * drm_mode_getconnector (ioctl)
> + * -> drm_helper_probe_single_connector_modes
> + *-> drm_bridge_connector_get_modes
> + * -> ps8640_bridge_get_edid
>
Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings
Sam Ravnborg 于2020年7月29日周三 上午4:27写道：
>
> Hi Kevin
>
> On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> > graphics subsystem
> >
> > Cc: Orson Zhai
> > Cc: Chunyan Zhang
> > Signed-off-by: Kevin Tang
> > ---
> > .../devicetree/bindings/display/sprd/drm.yaml | 36
> > ++
> > 1 file changed, 36 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml
> > b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> > new file mode 100644
> > index 000..b5792c0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> drm seems like a sub-optimal name.
> How about usign the compatible name "display-subsystem" as it is a bit
> more specific (but not good).
You're right, maybe "sprd,drm.yaml" or "sprd-drm.yaml" will be better
>
> > @@ -0,0 +1,36 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Any chance this can be (GPL-2.0-only OR BSD-2-Clause).
> I noticed that for example clock/sprd,sc9863a-clk.yaml uses this license
> so I hope this is OK.
I will add GPL-2.0-only to it.
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Unisoc DRM master device
> > +
> > +maintainers:
> > + - Mark Rutland
> > +
> > +description: |
> > + The Unisoc DRM master device is a virtual device needed to list all
> > + DPU devices or other display interface nodes that comprise the
> > + graphics subsystem.
> > +
> > +properties:
> > + compatible:
> > +const: sprd,display-subsystem
> > +
> > + ports:
> > +description:
> > + Should contain a list of phandles pointing to display interface port
> > + of DPU devices.
> Add type - like this:
> $ref: /schemas/types.yaml#/definitions/phandle-array
>
> See for example display/rockchip/rockchip-drm.yaml
>
> Any specific reason why this is not a ports node like used by many other
> display bindings?
> In other words - I think this is too simple.
We only support one display pipeline now, other interface, like
DP(DisplayPort), HDMI...will be add later...
ports:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Should contain a list of phandles pointing to display interface port
of dpu devices.. dpu definitions as defined in
Documentation/devicetree/bindings/display/sprd/sprd,dpu.yaml
>
> > +
> > +required:
> > + - compatible
> > + - ports
> > +
>
> Add:
> additionalProperties: false
>
> so we catch if other properties sneak in.
>
> > +examples:
> > + - |
> > +display-subsystem {
> > +compatible = "sprd,display-subsystem";
> > +ports = <&dpu_out>;
> > +};
> > +
> > --
> > 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 0/8] Convert the intel iommu driver to the dma-iommu api
That would be great! On Wed., Aug. 26, 2020, 2:14 p.m. Robin Murphy, wrote: > Hi Tom, > > On 2019-12-21 15:03, Tom Murphy wrote: > > This patchset converts the intel iommu driver to the dma-iommu api. > > > > While converting the driver I exposed a bug in the intel i915 driver > which causes a huge amount of artifacts on the screen of my laptop. You can > see a picture of it here: > > > https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > > > > This issue is most likely in the i915 driver and is most likely caused > by the driver not respecting the return value of the dma_map_ops::map_sg > function. You can see the driver ignoring the return value here: > > > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > > > Previously this didn’t cause issues because the intel map_sg always > returned the same number of elements as the input scatter gather list but > with the change to this dma-iommu api this is no longer the case. I wasn’t > able to track the bug down to a specific line of code unfortunately. > > > > Could someone from the intel team look at this? > > > > > > I have been testing on a lenovo x1 carbon 5th generation. Let me know if > there’s any more information you need. > > > > To allow my patch set to be tested I have added a patch (patch 8/8) in > this series to disable combining sg segments in the dma-iommu api which > fixes the bug but it doesn't fix the actual problem. > > > > As part of this patch series I copied the intel bounce buffer code to > the dma-iommu path. The addition of the bounce buffer code took me by > surprise. I did most of my development on this patch series before the > bounce buffer code was added and my reimplementation in the dma-iommu path > is very rushed and not properly tested but I’m running out of time to work > on this patch set. > > > > On top of that I also didn’t port over the intel tracing code from this > commit: > > > https://github.com/torvalds/linux/commit/3b53034c268d550d9e8522e613a14ab53b8840d8#diff-6b3e7c4993f05e76331e463ab1fc87e1 > > So all the work in that commit is now wasted. The code will need to be > removed and reimplemented in the dma-iommu path. I would like to take the > time to do this but I really don’t have the time at the moment and I want > to get these changes out before the iommu code changes any more. > > Further to what we just discussed at LPC, I've realised that tracepoints > are actually something I could do with *right now* for debugging my Arm > DMA ops series, so if I'm going to hack something up anyway I may as > well take responsibility for polishing it into a proper patch as well :) > > Robin. > > > > > Tom Murphy (8): > >iommu/vt-d: clean up 32bit si_domain assignment > >iommu/vt-d: Use default dma_direct_* mapping functions for direct > > mapped devices > >iommu/vt-d: Remove IOVA handling code from non-dma_ops path > >iommu: Handle freelists when using deferred flushing in iommu drivers > >iommu: Add iommu_dma_free_cpu_cached_iovas function > >iommu: allow the dma-iommu api to use bounce buffers > >iommu/vt-d: Convert intel iommu driver to the iommu ops > >DO NOT MERGE: iommu: disable list appending in dma-iommu > > > > drivers/iommu/Kconfig | 1 + > > drivers/iommu/amd_iommu.c | 14 +- > > drivers/iommu/arm-smmu-v3.c | 3 +- > > drivers/iommu/arm-smmu.c| 3 +- > > drivers/iommu/dma-iommu.c | 183 +-- > > drivers/iommu/exynos-iommu.c| 3 +- > > drivers/iommu/intel-iommu.c | 936 > > drivers/iommu/iommu.c | 39 +- > > drivers/iommu/ipmmu-vmsa.c | 3 +- > > drivers/iommu/msm_iommu.c | 3 +- > > drivers/iommu/mtk_iommu.c | 3 +- > > drivers/iommu/mtk_iommu_v1.c| 3 +- > > drivers/iommu/omap-iommu.c | 3 +- > > drivers/iommu/qcom_iommu.c | 3 +- > > drivers/iommu/rockchip-iommu.c | 3 +- > > drivers/iommu/s390-iommu.c | 3 +- > > drivers/iommu/tegra-gart.c | 3 +- > > drivers/iommu/tegra-smmu.c | 3 +- > > drivers/iommu/virtio-iommu.c| 3 +- > > drivers/vfio/vfio_iommu_type1.c | 2 +- > > include/linux/dma-iommu.h | 3 + > > include/linux/intel-iommu.h | 1 - > > include/linux/iommu.h | 32 +- > > 23 files changed, 345 insertions(+), 908 deletions(-) > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: For MST hub, Get max_link_rate&max_lane from extended rx capability field if EXTENDED_RECEIVER_CAPABILITY_FILED_PRESENT is set.
Currently, DRM get the capability of the mst hub only from DP_DPCD_REV and
get the slower speed even the mst hub can run in the faster speed.
As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1, read the DP_DP13_DPCD_REV to
get the faster capability.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0, read DP_DPCD_REV.
Signed-off-by: Koba Ko
---
drivers/gpu/drm/drm_dp_mst_topology.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..3b84c6801281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3497,6 +3497,8 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
dp_link_count)
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool
mst_state)
{
int ret = 0;
+ u8 dpcd_ext = 0;
+ unsigned int dpcd_offset = 0;
struct drm_dp_mst_branch *mstb = NULL;
mutex_lock(&mgr->payload_lock);
@@ -3510,9 +3512,15 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
struct drm_dp_payload reset_pay;
WARN_ON(mgr->mst_primary);
+ drm_dp_dpcd_read(mgr->aux,
+DP_TRAINING_AUX_RD_INTERVAL,
+&dpcd_ext, sizeof(dpcd_ext));
+
+ dpcd_offset =
+ ((dpcd_ext & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) ?
DP_DP13_DPCD_REV : DP_DPCD_REV);
/* get dpcd info */
- ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
DP_RECEIVER_CAP_SIZE);
+ ret = drm_dp_dpcd_read(mgr->aux, dpcd_offset, mgr->dpcd,
DP_RECEIVER_CAP_SIZE);
if (ret != DP_RECEIVER_CAP_SIZE) {
DRM_DEBUG_KMS("failed to read DPCD\n");
goto out_unlock;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: virtio: fix kconfig dependency warning
From: Randy Dunlap Fix kconfig dependency warning by using a different Kconfig symbol. WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y] Selected by [y]: - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y] Signed-off-by: Randy Dunlap Cc: David Airlie Cc: Gerd Hoffmann Cc: dri-devel@lists.freedesktop.org Cc: virtualizat...@lists.linux-foundation.org --- Found in linux-next but applies to mainline. drivers/gpu/drm/virtio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200826.orig/drivers/gpu/drm/virtio/Kconfig +++ linux-next-20200826/drivers/gpu/drm/virtio/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO && MMU + depends on DRM && VIRTIO_MENU && MMU select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER select VIRTIO_DMA_SHARED_BUFFER ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags
Bridge drivers that implement the new model only shall return an error from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not set. So make sure we return an error because only the new drm_bridge model is supported. Reviewed-by: Sam Ravnborg Signed-off-by: Enric Balletbo i Serra --- Changes in v2: None drivers/gpu/drm/bridge/parade-ps8640.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 13755d278db6..ce3e8b2da8c9 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -200,6 +200,10 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge, .channel = 0, .node = NULL, }; + + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) + return -EINVAL; + /* port@0 is ps8640 dsi input port */ in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1); if (!in_ep) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags
On Wed, 26 Aug 2020 10:15:24 +0200 Enric Balletbo i Serra wrote: > Bridge drivers that implement the new model only shall return an error > from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR > flag is not set. So make sure we return an error because only the new > drm_bridge model is supported. > > Reviewed-by: Sam Ravnborg > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v2: None > > drivers/gpu/drm/bridge/parade-ps8640.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c index > 13755d278db6..ce3e8b2da8c9 100644 --- > a/drivers/gpu/drm/bridge/parade-ps8640.c +++ > b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -200,6 +200,10 @@ static > int ps8640_bridge_attach(struct drm_bridge *bridge, .channel = 0, > .node = NULL, >}; > + > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) > + return -EINVAL; > + > /* port@0 is ps8640 dsi input port */ > in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1); > if (!in_ep) Reviewed-by: Bilal Wasim Tested-by: Bilal Wasim -Bilal ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Add a "knob", like drm.debug, to map bits to these classes.
bash-5.0# echo 0x01 > /sys/module/i915/parameters/debug_dyn
set_dyndbg: result:0x1 from 0x01
dyndbg: query 0: "format='^gvt: cmd: ' +p"
dyndbg: entry, buf:'format='^gvt: cmd: ' +p'
dyndbg: start-of-word:0 'format='^gvt: cmd: ' +p'
dyndbg: start-of-word:1 ''^gvt: cmd: ' +p'
dyndbg: start-of-word:2 '+p'
dyndbg: split into words: "format" "^gvt: cmd: " "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: key:'format' arg:'^gvt: cmd: '
dyndbg: parsed: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:3081
[i915]init_cmd_table =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1376
[i915]gen8_check_mi_display_flip =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:1373
[i915]gen8_check_mi_display_flip =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:745
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:744
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:742
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:733
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:729
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:722
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:716
[i915]parser_exec_state_dump =p
dyndbg: changed drivers/gpu/drm/i915/gvt/cmd_parser.c:691 [i915]print_opcode =p
dyndbg: applied: func="" file="" module="i915" format="^gvt: cmd: " lineno=0-0
dyndbg: processed 1 queries, with 11 matches, 0 errs
change ct:11 on format='gvt: cmd: '
change ct:11
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/i915/i915_params.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 8d8db9ff0a48..4e1f01ab4865 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -255,3 +255,79 @@ void i915_params_free(struct i915_params *params)
I915_PARAMS_FOR_EACH(FREE);
#undef FREE
}
+
+/* POC for callback -> dynamic_debug_exec_queries */
+unsigned long __new_knob;
+EXPORT_SYMBOL(__new_knob);
+
+static char *pr_debug_classes[] = {
+ "gvt: cmd: ",
+ "gvt: core: ",
+ "gvt: dpy: ",
+ "gvt: el: ",
+ "gvt: irq: ",
+ "gvt: mm: ",
+ "gvt: mmio: ",
+ "gvt: render: ",
+ "gvt: sched: "
+};
+#define NUM_CLASSESARRAY_SIZE(pr_debug_classes)
+#define OUR_QUERY_SIZE 128 /* we need about 20 */
+
+#include
+
+static int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
+{
+ static unsigned long int old_val;
+unsigned int val;
+ unsigned long int changes, result;
+ int rc, chgct = 0, totct = 0, bitpos;
+ char query[OUR_QUERY_SIZE];
+
+ rc = kstrtouint(instr, 0, &val);
+ if (rc) {
+ pr_err("set_dyndbg: failed\n");
+ return -EINVAL;
+ }
+ result = val;
+ pr_info("set_dyndbg: result:0x%lx from %s\n", result, instr);
+
+ changes = result ^ old_val;
+
+ for_each_set_bit(bitpos, &changes, NUM_CLASSES) {
+
+ sprintf(query, "format='^%s' %cp", pr_debug_classes[bitpos],
+ test_bit(bitpos, &result) ? '+' : '-');
+
+ chgct = dynamic_debug_exec_queries(query, "i915");
+ totct += chgct;
+ pr_info("change ct:%d on format='%s'\n", chgct,
+ pr_debug_classes[bitpos]);
+ }
+ old_val = result;
+ pr_info("change ct:%d\n", totct);
+ return 0;
+}
+static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
+{
+ return scnprintf(buffer, PAGE_SIZE, "%u\n",
+*((unsigned int *)kp->arg));
+}
+static const struct kernel_param_ops param_ops_dyndbg = {
+ .set = param_set_dyndbg,
+ .get = param_get_dyndbg,
+};
+
+MODULE_PARM_DESC(debug_dyn, " enable dynamic-debug by format-string
classifications.\n"
+"\t\twhich are:"
+"\n\t\t gvt: cmd:"
+"\n\t\t gvt: core:"
+"\n\t\t gvt: dpy:"
+"\n\t\t gvt: el:"
+"\n\t\t gvt: irq:"
+"\n\t\t gvt: mm:"
+"\n\t\t gvt: mmio:"
+"\n\t\t gvt: render:"
+"\n\t\t gvt: sched:" "\n");
+
+module_param_cb(debug_dyn, ¶m_ops_dyndbg, &__new_knob, 0644);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/bridge: ps8640: Get the EDID from eDP control
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.
Reviewed-by: Laurent Pinchart
Acked-by: Sam Ravnborg
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2:
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`
drivers/gpu/drm/bridge/parade-ps8640.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
}
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ return drm_get_edid(connector,
+ ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+ .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
};
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+ ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+ ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
ps_bridge->page[PAGE0_DP_CNTL] = client;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Is: virtio_gpu_object_shmem_init issues? Was:Re: upstream boot error: general protection fault in swiotlb_map
Hello, I had a similiar panic when booting an ARM VM with kernel v5.9-rc1. git bisect identified following bad commit. After reverting the bad commit, the VM boot ok. Maybe we should look into the following commit. d323bb44e4d23802eb25d13de1f93f2335bd60d0 is the first bad commit commit d323bb44e4d23802eb25d13de1f93f2335bd60d0 Author: Daniel Vetter Date: Mon May 11 11:35:49 2020 +0200 drm/virtio: Call the right shmem helpers drm_gem_shmem_get_sg_table is meant to implement obj->funcs->get_sg_table, for prime exporting. The one we want is drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not just native objects. v2: Rebase, this stuff moved around in commit 2f2aa13724d56829d910b2fa8e80c502d388f106 Author: Gerd Hoffmann Date: Fri Feb 7 08:46:38 2020 +0100 drm/virtio: move virtio_gpu_mem_entry initialization to new function Acked-by: Thomas Zimmermann Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-5-daniel.vet...@ffwll.ch Thank you, Thomas On 2020-08-24 11:06 a.m., Konrad Rzeszutek Wilk wrote: On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90 kernel config: https://syzkaller.appspot.com/x/.config?x=7c06047f622c5724 dashboard link: https://syzkaller.appspot.com/bug?extid=3f86afd0b1e4bf1cb64c compiler: gcc (GCC) 10.1.0-syz 20200507 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3f86afd0b1e4bf1cb...@syzkaller.appspotmail.com ceph: loaded (mds proto 32) NET: Registered protocol family 38 async_tx: api initialized (async) Key type asymmetric registered Asymmetric key parser 'x509' registered Asymmetric key parser 'pkcs8' registered Key type pkcs7_test registered Asymmetric key parser 'tpm_parser' registered Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243) io scheduler mq-deadline registered io scheduler kyber registered io scheduler bfq registered hgafb: HGA card not detected. hgafb: probe of hgafb.0 failed with error -22 usbcore: registered new interface driver udlfb uvesafb: failed to execute /sbin/v86d uvesafb: make sure that the v86d helper is installed and executable uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 vga16fb: mapped to 0x8aac772d Console: switching to colour frame buffer device 80x30 fb0: VGA16 VGA frame buffer device input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 ACPI: Power Button [PWRF] ioatdma: Intel(R) QuickData Technology Driver 5.00 PCI Interrupt Link [GSIF] enabled at IRQ 21 PCI Interrupt Link [GSIG] enabled at IRQ 22 PCI Interrupt Link [GSIH] enabled at IRQ 23 N_HDLC line discipline registered with maxframe=4096 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A Cyclades driver 2.6 Initializing Nozomi driver 2.1d RocketPort device driver module, version 2.09, 12-June-2003 No rocketport ports found; unloading driver Non-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0 [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1 usbcore: registered new interface driver udl [drm] pci: virtio-vga detected at :00:01.0 fb0: switching to virtiodrmfb from VGA16 VGA Console: switching to colour VGA+ 80x25 virtio-pci :00:01.0: vgaarb: deactivate vga console Console: switching to colour dummy device 80x25 [drm] features: -virgl +edid [drm] number of scanouts: 1 [drm] number of cap sets: 0 [drm] Initialized virtio_gpu 0.1.0 0 for virtio0 on minor 2 general protection fault, probably for non-canonical address 0xdc00: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x-0x0007] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:swiotlb_map+0x5ac/0x700 kernel/dma/swiotlb.c:683 Code: 28 04 00 00 48 c1 ea 03 80 3c 02 00 0f 85 4d 01 00 00 4c 8b a5 18 04 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 01 00 00 48 8d 7d 50 4d 8b 24 24 48 b8 00 00 RSP: :c934f3e0 EFLAGS: 00010246 RAX: dc00 RBX: RCX: 8162cc1d RDX: RSI: 8162cc98 RDI: 88802971a470 RBP: 88802971a048 R08: 0001 R09: 8c5dba77 R10: R11: R12: R13: 7ac0 R14: d
Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge
Hi Bilal, On 24/8/20 21:01, Bilal Wasim wrote: > Hi Chun-Kuan, Enric, > > Is there any plan to merge the following commits in this series to the > mainline? > > drm/bridge: ps8640: Get the EDID from eDP control > drm/bridge_connector: Set default status connected for eDP connectors > Just sent a new series including this patches: https://lore.kernel.org/patchwork/project/lkml/list/?series=459760 Thanks, Enric > I see that rest of the patchset is already merged and available in 5.9-RC2. > > Thanks, > Bilal > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Parse Colorimetry data block from EDID
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
Signed-off-by: Algea Cao
---
drivers/gpu/drm/drm_edid.c | 45 +
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 14
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31496b6cfc56..67e607c04492 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
@@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 2)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
+ if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
+ /* Byte 4 Bit 7: DCI-P3 */
+ if (db[3] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
+
+ DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
+}
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index af145608b5ed..d599c3b9e881 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index cfa4f5af49af..98fa78c2f82d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,20 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/*
+ * Supported Colorimetry from colorimetry data block
+ * as per CEA 861-G spec
+ */
+#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
+#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
+#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
+#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
+#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
+#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
+#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
+#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
+#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
From: kernel test robot
Use kobj_to_dev() instead of container_of()
Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
CC: Denis Efremov
Signed-off-by: kernel test robot
Signed-off-by: Julia Lawall
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git
for-5.10
head: a2fc3718bc22e85378085568ecc5765fb28cabce
commit: a2fc3718bc22e85378085568ecc5765fb28cabce [3/3] coccinelle: api: add
kobj_to_dev.cocci script
:: branch date: 5 days ago
:: commit date: 5 days ago
udlfb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1457,7 +1457,7 @@ static ssize_t edid_show(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
char *buf, loff_t off, size_t count) {
- struct device *fbdev = container_of(kobj, struct device, kobj);
+ struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;
@@ -1479,7 +1479,7 @@ static ssize_t edid_store(
struct file *filp,
struct kobject *kobj, struct bin_attribute *a,
char *src, loff_t src_off, size_t src_size) {
- struct device *fbdev = container_of(kobj, struct device, kobj);
+ struct device *fbdev = kobj_to_dev(kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dlfb = fb_info->par;
int ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] make hdmi work on bananapi-r2
Just a gentle ping...any opinions? regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails
On Wed, 26 Aug 2020 10:15:25 +0200
Enric Balletbo i Serra wrote:
> Print an error message inside ps8640_bridge_vdo_control() function
> when it fails so we can simplify a bit the callers, they will only
> need to check the error code.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c index
> ce3e8b2da8c9..9f7b7a9c53c5 100644 ---
> a/drivers/gpu/drm/bridge/parade-ps8640.c +++
> b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -82,8 +82,11 @@ static
> int ps8640_bridge_vdo_control(struct ps8640 *ps_bridge, ret =
> i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
> sizeof(vdo_ctrl_buf), vdo_ctrl_buf);
> - if (ret < 0)
> + if (ret < 0) {
> + DRM_ERROR("failed to %sable VDO: %d\n",
> + ctrl == ENABLE ? "en" : "dis", ret);
> return ret;
> + }
>
> return 0;
> }
> @@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge
> *bridge) }
>
> ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
> - if (ret) {
> - DRM_ERROR("failed to enable VDO: %d\n", ret);
> + if (ret)
> goto err_regulators_disable;
> - }
>
> /* Switch access edp panel's edid through i2c */
> ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
> @@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge
> *bridge) struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> int ret;
>
> - ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> - if (ret < 0)
> - DRM_ERROR("failed to disable VDO: %d\n", ret);
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>
> gpiod_set_value(ps_bridge->gpio_reset, 1);
> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
Reviewed-by: Bilal Wasim
Tested-by: Bilal Wasim
-Bilal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] drm/bridge: ps8640: Make sure all needed is powered to get the EDID
The first patch was initially part of the series [1] but for some reason was not picked when the series were merged, so I included in this series because it is needed to make the others to work properly. The same happened for the second patch, was part of series [1] but not merged. The third patch and next are part of the original series and are to rework the power handling to get the EDID. Basically, we need to make sure all the needed is powered to be able to get the EDID. Before, we saw that getting the EDID failed as explained in the third patch. [1] https://lkml.org/lkml/2020/6/15/1208 Changes in v2: - Included the patch `drm/bridge_connector: Set default status connected for eDP connectors` - Included the patch `drm/bridge: ps8640: Get the EDID from eDP control` - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg) Enric Balletbo i Serra (5): drm/bridge_connector: Set default status connected for eDP connectors drm/bridge: ps8640: Get the EDID from eDP control drm/bridge: ps8640: Return an error for incorrect attach flags drm/bridge: ps8640: Print an error if VDO control fails drm/bridge: ps8640: Rework power state handling drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++ drivers/gpu/drm/drm_bridge_connector.c | 1 + 2 files changed, 79 insertions(+), 11 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] i915: add -DDYNAMIC_DEBUG_MODULE to i915/gvt/Makefile
This addition to cflags enables dyndbg in the gvt component of the
i915 module, on a CONFIG_DYNAMIC_DEBUG_CORE build.
So here are the message classifications that the gvt driver uses.
cut -d= -f2 | cut -d\ -f2,3 | \
perl -ne 'chomp $_ && $h{$_}++; END{print "$_\" \tseen $h{$_}\n" for sort
keys %h}'
"gvt: cmd:" seen 11
"gvt: core:"seen 48
"gvt: dpy:" seen 4
"gvt: el:" seen 21
"gvt: irq:" seen 1
"gvt: mm:" seen 6
"gvt: mmio:"seen 9
"gvt: render:" seen 1
"gvt: sched:" seen 15
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/i915/gvt/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..2c581e910688 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
-ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
-i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
+ccflags-y += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/
+ccflags-y += -DDYNAMIC_DEBUG_MODULE
+i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails
Print an error message inside ps8640_bridge_vdo_control() function when
it fails so we can simplify a bit the callers, they will only need to
check the error code.
Reviewed-by: Sam Ravnborg
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index ce3e8b2da8c9..9f7b7a9c53c5 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -82,8 +82,11 @@ static int ps8640_bridge_vdo_control(struct ps8640
*ps_bridge,
ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
sizeof(vdo_ctrl_buf),
vdo_ctrl_buf);
- if (ret < 0)
+ if (ret < 0) {
+ DRM_ERROR("failed to %sable VDO: %d\n",
+ ctrl == ENABLE ? "en" : "dis", ret);
return ret;
+ }
return 0;
}
@@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
}
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
- if (ret) {
- DRM_ERROR("failed to enable VDO: %d\n", ret);
+ if (ret)
goto err_regulators_disable;
- }
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
@@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
- ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
- if (ret < 0)
- DRM_ERROR("failed to disable VDO: %d\n", ret);
+ ps8640_bridge_vdo_control(ps_bridge, DISABLE);
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling
The get_edid() callback can be triggered anytime by an ioctl, i.e
drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
-> drm_bridge_connector_get_modes
-> ps8640_bridge_get_edid
Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.
To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:
1. If get_edid() is called before having the device powered we need to
power on the device. In such case, the driver will power off again the
device.
2. If get_edid() is called after having the device powered, all should
just work. We added a powered flag in order to avoid recurrent calls
to ps8640_bridge_poweron() and unneeded delays.
3. This seems to be specific for this device, but we need to make sure
the panel is powered on before do a power on cycle on this device.
Otherwise the device fails to retrieve the EDID.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
1 file changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..c5d76e209bda 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+ bool powered;
};
static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640
*ps_bridge,
return 0;
}
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
{
- struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
+ if (ps_bridge->powered)
+ return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
+ ps_bridge->powered = true;
+
return;
err_regulators_disable:
@@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
ps_bridge->supplies);
}
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
{
- struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
- ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+ if (!ps_bridge->powered)
+ return;
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+ ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+ int ret;
+
+ ps8640_bridge_poweron(ps_bridge);
+
+ ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+ if (ret < 0)
+ ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+ ps8640_bridge_poweroff(ps_bridge);
}
static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +276,34 @@ static struct edid *ps8640_bridge_get_edid(struct
drm_bridge *bridge,
struct drm_connector *connector)
{
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+ bool poweroff = !ps_bridge->powered;
+ struct edid *edid;
+
+ /*
+* When we end calling get_edid() triggered by an ioctl, i.e
+*
+* drm_mode_getconnector (ioctl)
+* -> drm_helper_probe_single_connector_modes
+*-> drm_bridge_connector_get_modes
+* -> ps8640_bridge_get_edid
+*
+* We need to make sure that what we need is enabled before reading
+* EDID, f
[PATCH 2/4] drm-printk: call pr_debug() from drm_dev_dbg, __drm_dbg
Put the pr_debug() after the vaf setup work, so as to use it. And
move the if-category-disabled-return after both, so the pr_debug()
runs unconditionally.
This lets both debug-printers execute independently, according to
their respective controls, allowing later comparison to each other.
#> echo module=drm +pmftl > /proc/dynamic_debug/control
yields logging like:
[1772] drm:drm_dev_dbg:305: i915 :00:02.0:
[drm:intel_atomic_get_global_obj_state [i915]]
Cat:16 Added new global object 6fa51dd6 state bbddcf9d to
5f6e1bc3
[1772] drm:drm_dev_dbg:305: i915 :00:02.0:
[drm:intel_atomic_get_global_obj_state [i915]]
Cat:16 Added new global object 2a5e020a state 2b3685ed to
5f6e1bc3
[198] drm:drm_dev_dbg:305: i915 :00:02.0: [drm:drm_update_vblank_count
[drm]]
Cat:32 updating vblank count on crtc 0: current=260920, diff=0, hw=192024
hw_last=192024
[1772] drm:__drm_dbg:331: [drm:drm_atomic_nonblocking_commit [drm]] Cat:16
committing 5f6e1bc3 nonblocking
[1772] drm:__drm_dbg:331: [drm:drm_mode_object_put.part.0 [drm]] Cat:1 OBJ ID:
113 (4)
[1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell"
pid=1772, dev=0xe200, auth=1, I915_GEM_CREATE
[1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell"
pid=1772, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
[1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell"
pid=1772, dev=0xe200, auth=1, I915_GEM_SET_TILING
[1772] drm:__drm_dbg:331: [drm:drm_ioctl [drm]] Cat:1 comm="gnome-shell"
pid=1772, dev=0xe200, auth=1, I915_GEM_MMAP_OFFSET
Clearly, the mflt flags arent very helpful here, and callsite control
is all or nothing (since theres only 2 callsites handling all the
categories). We are 1 below the function layer of interest, but
theres room for optimism.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 52abaf2ae053..fa2bcf4ec475 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -27,6 +27,7 @@
#include
+#define DYNAMIC_DEBUG_MODULE
#include
#include
#include
@@ -61,17 +62,17 @@ EXPORT_SYMBOL(__drm_debug2);
static int param_set_dyndbg(const char *val, const struct kernel_param *kp)
{
- int chgct, result;
+ int chgct, rc, result;
- result = kstrtouint(val, 0, (unsigned int *)kp->arg);
- pr_warn("set_dyndbg: result:%d from %s\n", result, val);
+ rc = kstrtouint(val, 0, &result);
+ pr_debug("set_dyndbg: rc:%d got:%d from %s\n", rc, result, val);
if (result)
chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
else
chgct = dynamic_debug_exec_queries("module=drm* -p", NULL);
- pr_warn("change ct:%d\n", chgct);
+ pr_debug("change ct:%d\n", chgct);
return 0;
}
static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
@@ -297,13 +298,16 @@ void drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
struct va_format vaf;
va_list args;
- if (!drm_debug_enabled(category))
- return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
+ dev_dbg(dev, "[" DRM_NAME ":%ps] Cat:%d %pV",
+ __builtin_return_address(0), category, &vaf);
+
+ if (!drm_debug_enabled(category))
+ return;
+
if (dev)
dev_printk(KERN_DEBUG, dev, "[" DRM_NAME ":%ps] %pV",
__builtin_return_address(0), &vaf);
@@ -320,13 +324,16 @@ void __drm_dbg(enum drm_debug_category category, const
char *format, ...)
struct va_format vaf;
va_list args;
- if (!drm_debug_enabled(category))
- return;
-
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
+ pr_debug("[" DRM_NAME ":%ps] Cat:%d %pV",
+__builtin_return_address(0), category, &vaf);
+
+ if (!drm_debug_enabled(category))
+ return;
+
printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
__builtin_return_address(0), &vaf);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver
Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)
drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+ struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
};
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
{
- return container_of(e, struct mtk_dpi, encoder);
+ return container_of(b, struct mtk_dpi, bridge);
}
enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
}
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
{
- return true;
+ drm_encoder_cleanup(encoder);
}
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+ .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
{
- struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+ struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+&dpi->bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode)
+{
+ struct mtk_dpi *dpi = bridge_to_dpi(bridge);
drm_mode_copy(&dpi->mode, adjusted_mode);
}
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
{
- struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+ struct mtk_dpi *dpi = bridge_to_dpi(bridge);
mtk_dpi_power_off(dpi);
}
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
{
- struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+ struct mtk_dpi *dpi = bridge_to_dpi(bridge);
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, &dpi->mode);
}
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
-{
- return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
- .mode_fixup = mtk_dpi_encoder_mode_fixup,
- .mode_set = mtk_dpi_encoder_mode_set,
- .disable = mtk_dpi_encoder_disable,
- .enable = mtk_dpi_encoder_enable,
- .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+ .attach = mtk_dpi_bridge_attach,
+ .mode_set = mtk_dpi_bridge_mode_set,
+ .disable = mtk_dpi_bridge_disable,
+ .enable = mtk_dpi_bridge_enable,
};
static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
- drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
- ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
+ ret = drm_bridge_attach(&dpi->encoder, &dpi->bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dpi);
+ dpi->bridge.funcs = &mtk_dpi_bridge_func
[PATCH 1/4] drm-printk: POC caller of dynamic-debug-exec-queries
Export of dynamic-debug-exec-queries exists for users like drm.
This commit is a 1st user-test; it adds a 2nd knob, __drm_debug2,
similar in function to __drm_debug. module_param_cb wires it to a
callback which maps the input value to one of: "module=drm* +/-p".
The include is needed to see the exported function prototype.
Notes:
The define DEBUG at top of drm-printk enables all pr_debug()s,
independent of CONFIG_DYNAMIC_DEBUG_CORE.
drm-printk is an independent print control system using __drm_debug
bits. The plan is to find the low-level macros in which to insert a
pr_debug call, their eventual callsites will have distinct METADATA,
so will be itemized in control, and individually selectable.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..52abaf2ae053 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -27,6 +27,7 @@
#include
+#include
#include
#include
#include
@@ -54,6 +55,40 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
module_param_named(debug, __drm_debug, int, 0600);
+/* POC for callback -> ddebug_exec_queries */
+unsigned int __drm_debug2;
+EXPORT_SYMBOL(__drm_debug2);
+
+static int param_set_dyndbg(const char *val, const struct kernel_param *kp)
+{
+ int chgct, result;
+
+ result = kstrtouint(val, 0, (unsigned int *)kp->arg);
+ pr_warn("set_dyndbg: result:%d from %s\n", result, val);
+
+ if (result)
+ chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
+ else
+ chgct = dynamic_debug_exec_queries("module=drm* -p", NULL);
+
+ pr_warn("change ct:%d\n", chgct);
+ return 0;
+}
+static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
+{
+ return scnprintf(buffer, PAGE_SIZE, "%u\n",
+*((unsigned int *)kp->arg));
+}
+static const struct kernel_param_ops param_ops_dyndbg = {
+ .set = param_set_dyndbg,
+ .get = param_get_dyndbg,
+};
+
+MODULE_PARM_DESC(debug_dyn, "Enable debug output, where each bit enables a
debug category.\n"
+"\t\tthese wont work yet\n");
+module_param_cb(debug_dyn, ¶m_ops_dyndbg, &__drm_debug2, 0644);
+
+
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
struct drm_print_iterator *iterator = p->arg;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dpi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
- struct drm_bridge *bridge;
+ struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
- ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
+ ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, &dpi->bridge);
+ NULL, &dpi->next_bridge);
if (ret)
return ret;
- dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+ dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
On 2020-08-25 04:27, Rob Herring wrote: On Mon, Aug 10, 2020 at 07:08:02PM +0530, Krishna Manikandan wrote: MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks like DPU display controller, DSI etc. Add YAML schema for the device tree bindings for the same. Signed-off-by: Krishna Manikandan Changes in v2: - Changed dpu to DPU (Sam Ravnborg) - Fixed indentation issues (Sam Ravnborg) - Added empty line between different properties (Sam Ravnborg) - Replaced reference txt files with their corresponding yaml files (Sam Ravnborg) - Modified the file to use "|" only when it is necessary (Sam Ravnborg) Changes in v3: - Corrected the license used (Rob Herring) - Added maxItems for properties (Rob Herring) - Dropped generic descriptions (Rob Herring) - Added ranges property (Rob Herring) - Corrected the indendation (Rob Herring) - Added additionalProperties (Rob Herring) - Split dsi file into two, one for dsi controller and another one for dsi phy per target (Rob Herring) - Corrected description for pinctrl-names (Rob Herring) - Corrected the examples used in yaml file (Rob Herring) - Delete dsi.txt and dpu.txt (Rob Herring) Changes in v4: - Move schema up by one level (Rob Herring) - Add patternProperties for mdp node (Rob Herring) - Corrected description of some properties (Rob Herring) Changes in v5: - Correct the indentation (Rob Herring) - Remove unnecessary description from properties (Rob Herring) - Correct the number of interconnect entries (Rob Herring) - Add interconnect names for sc7180 (Rob Herring) - Add description for ports (Rob Herring) - Remove common properties (Rob Herring) - Add unevalutatedProperties (Rob Herring) - Reference existing dsi controller yaml in the common dsi controller file (Rob Herring) - Correct the description of clock names to include only the clocks that are required (Rob Herring) - Remove properties which are already covered under the common binding (Rob Herring) - Add dsi phy supply nodes which are required for sc7180 and sdm845 targets (Rob Herring) - Add type ref for syscon-sfpb (Rob Herring) Changes in v6: - Fixed errors during dt_binding_check (Rob Herring) - Add maxItems for phys and phys-names (Rob Herring) - Use unevaluatedProperties wherever required (Rob Herring) - Removed interrupt controller from required properties for dsi controller (Rob Herring) - Add constraints for dsi-phy reg-names based on the compatible phy version (Rob Herring) - Add constraints for dsi-phy supply nodes based on the compatible phy version (Rob Herring) Changes in v7: - Add default value for qcom,mdss-mdp-transfer-time-us (Rob Herring) - Modify the schema for data-lanes (Rob Herring) - Split the phy schema into separate schemas based on the phy version (Rob Herring) Changes in v8: - Resolve merge conflicts with latest dsi.txt file - Include dp yaml change also in the same series I'm done reviewing this because I'm tired of repeating myself and you're just throwing crap at the wall and seeing what sticks. Get someone else working on QCom stuff to review because I'm done until someone I know and trust reviews it. --- .../bindings/display/msm/dpu-sc7180.yaml | 236 +++ .../bindings/display/msm/dpu-sdm845.yaml | 216 ++ .../devicetree/bindings/display/msm/dpu.txt| 141 .../display/msm/dsi-common-controller.yaml | 249 + .../display/msm/dsi-controller-sc7180.yaml | 120 ++ .../display/msm/dsi-controller-sdm845.yaml | 120 ++ Once again, what's the difference between dsi-controller-sc7180.yaml and dsi-controller-sdm845.yaml? I don't see one. If there's not a difference, why do we have msm/dsi-common-controller.yaml? If there is a difference dsi-controller-sc7180.yaml and dsi-controller-sdm845.yaml should *only* have what's different because msm/dsi-common-controller.yaml should have everything that is the same. Rob, The dsi yaml files were split into dsi controller and dsi phy based on your comments on patch v2. As per the comments, I added one common yaml file for controller with all the mandatory and optional properties along with their constraints and only the required properties for each target is mentioned in the target specific dsi-controller yaml file. Thanks, Krishna .../bindings/display/msm/dsi-phy-10nm.yaml | 62 + .../bindings/display/msm/dsi-phy-14nm.yaml | 62 + .../bindings/display/msm/dsi-phy-20nm.yaml | 66 ++ .../bindings/display/msm/dsi-phy-28nm.yaml | 62 + .../bindings/display/msm/dsi-phy-sc7180.yaml | 80 +++ .../bindings/display/msm/dsi-phy-sdm845.yaml | 82 +++ .../devicetree/bindings/display/msm
RE: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Hi Laurent, > -Original Message- > From: Laurent Pinchart > Sent: Tuesday, August 11, 2020 5:30 > To: Yuti Suresh Amonkar > Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; > devicet...@vger.kernel.org; robh...@kernel.org; max...@cerno.tech; > airl...@linux.ie; dan...@ffwll.ch; mark.rutl...@arm.com; > a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se; > jernej.skra...@siol.net; prane...@ti.com; jsa...@ti.com; > tomi.valkei...@ti.com; Milind Parab ; Swapnil > Kashinath Jakhade > Subject: Re: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP > DPI/DP bridge > > EXTERNAL MAIL > > > Hi Yuti, > > On Fri, May 01, 2020 at 07:32:58AM +, Yuti Suresh Amonkar wrote: > > Hi Laurent, > > > > Thank you so much for reviewing the patch and providing valuable > > comments. Apologies for the delayed response. We are working on your > > review comments and will send the next version of the driver for > > review soon. Please see the responses to comments inline below. > > Thank you for the answers. I was reviewing v8 and realized there were a > few things I didn't fully understand related to communication with the > firmware, so I have a few questions here. > > > On Thursday, March 12, 2020 3:51, Laurent Pinchart wrote: > > > On Wed, Feb 26, 2020 at 11:22:58AM +0100, Yuti Amonkar wrote: > > > > This patch adds new DRM driver for Cadence MHDP DPTX IP used on > J721e SoC. > > > > > > s/DRM driver/DRM bridge driver. > > > > > > > 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 > > > > > > s/output/outputs/ > > > > > > > format. Currently, it supports only SST mode. > > > > > > > > Signed-off-by: Yuti Amonkar > > > > Signed-off-by: Jyri Sarha > > > > Signed-off-by: Quentin Schulz > > > > Signed-off-by: Swapnil Jakhade > > > > Signed-off-by: Tomi Valkeinen > > > > --- > > > > drivers/gpu/drm/bridge/Kconfig | 11 + > > > > drivers/gpu/drm/bridge/Makefile |2 + > > > > drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2196 > +++ > > > > drivers/gpu/drm/bridge/cdns-mhdp-core.h | 380 > > > > 4 files changed, 2589 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c > > > > create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > b/drivers/gpu/drm/bridge/Kconfig > > > > index 20a439199cb8..3bfabb76f2bb 100644 > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > @@ -27,6 +27,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 > > > > > > s/output/outputs/ > > > > > > > + 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 b0d5c3af0b5a..2e2c5be7c714 100644 > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > @@ -16,6 +16,8 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358768) += > tc358768.o > > > > 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) += cdns-mhdp.o > > > > > > Should this be kept alphabetically sorted ? > > > > > > > +cdns-mhdp-objs := cdns-mhdp-core.o > > > > > > > > obj-y += analogix/ > > > > obj-y += synopsys/ > > > > diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c > b/drivers/gpu/drm/bridge/cdns-mhdp-core.c > > > > new file mode 100644 > > > > index ..cc642893baa8 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c > > > > @@ -0,0 +1,2196 @@ > > > > +// 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 > > >
[PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors
In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Reviewed-by: Laurent Pinchart Acked-by: Sam Ravnborg Signed-off-by: Enric Balletbo i Serra --- Changes in v2: - Included the patch `drm/bridge_connector: Set default status connected for eDP connectors` drivers/gpu/drm/drm_bridge_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c index c6994fe673f3..a58cbde59c34 100644 --- a/drivers/gpu/drm/drm_bridge_connector.c +++ b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS: case DRM_MODE_CONNECTOR_DSI: + case DRM_MODE_CONNECTOR_eDP: status = connector_status_connected; break; default: -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: Removed the dependency on the mmu
hibmc can only be used in ARM64 architectures, and mmu defaults to y in arch/arm64/Kconfig, so there is no need to add a dependency on mmu in hibmc's kconfig. Signed-off-by: Tian Tao --- drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig index dfc5aef..43943e9 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_HISI_HIBMC tristate "DRM Support for Hisilicon Hibmc" - depends on DRM && PCI && MMU && ARM64 + depends on DRM && PCI && ARM64 select DRM_KMS_HELPER select DRM_VRAM_HELPER select DRM_TTM -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/2] i2c: i2c-qcom-geni: Add shutdown callback for i2c
Hi Roja,
On 8/20/2020 4:05 PM, Roja Rani Yarubandi wrote:
If the hardware is still accessing memory after SMMU translation
is disabled (as part of smmu shutdown callback), then the
IOVAs (I/O virtual address) which it was using will go on the bus
as the physical addresses which will result in unknown crashes
like NoC/interconnect errors.
So, implement shutdown callback to i2c driver to unmap DMA mappings
during system "reboot" or "shutdown".
Signed-off-by: Roja Rani Yarubandi
---
Changes in V2:
- As per Stephen's comments added seperate function for stop transfer,
fixed minor nitpicks.
drivers/i2c/busses/i2c-qcom-geni.c | 43 ++
include/linux/qcom-geni-se.h | 5
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 1fda5c7c2cfc..d07f2f33bb75 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -486,6 +486,28 @@ static int geni_i2c_xfer(struct i2c_adapter *adap,
return ret;
}
+static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
+{
+ u32 val;
+ struct geni_se *se = &gi2c->se;
+
+ val = readl_relaxed(gi2c->se.base + SE_DMA_DEBUG_REG0);
+ if (val & DMA_TX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_wr = 0;
+ if (gi2c->err)
+ geni_i2c_tx_fsm_rst(gi2c);
+ geni_se_tx_dma_unprep(se, gi2c->tx_dma, gi2c->xfer_len);
+ }
should be 'else if', because TX and RX can't happen parallel.
+ if (val & DMA_RX_ACTIVE) {
+ geni_i2c_abort_xfer(gi2c);
+ gi2c->cur_rd = 0;
+ if (gi2c->err)
+ geni_i2c_rx_fsm_rst(gi2c);
+ geni_se_rx_dma_unprep(se, gi2c->rx_dma, gi2c->xfer_len);
+ }
+}
+
static u32 geni_i2c_func(struct i2c_adapter *adap)
{
return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
@@ -617,6 +639,26 @@ static int geni_i2c_remove(struct platform_device *pdev)
return 0;
}
+static void geni_i2c_shutdown(struct platform_device *pdev)
+{
+ int ret;
+ u32 dma;
+ struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
+ struct geni_se *se = &gi2c->se;
+
+ ret = pm_runtime_get_sync(gi2c->se.dev);
+ if (ret < 0) {
+ dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret);
+ return;
+ }
+
+ dma = readl_relaxed(se->base + SE_GENI_DMA_MODE_EN);
Wrt to current issue context it may be suffice to stop just DMA mode
transfers but why not stop all mode of active transfer during shutdown
in a generic way.
Regards,
Akash
+ if (dma)
+ geni_i2c_stop_xfer(gi2c);
+
+ pm_runtime_put_sync_suspend(gi2c->se.dev);
+}
+
static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
{
int ret;
@@ -677,6 +719,7 @@ MODULE_DEVICE_TABLE(of, geni_i2c_dt_match);
static struct platform_driver geni_i2c_driver = {
.probe = geni_i2c_probe,
.remove = geni_i2c_remove,
+ .shutdown = geni_i2c_shutdown,
.driver = {
.name = "geni_i2c",
.pm = &geni_i2c_pm_ops,
diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
index dd464943f717..c3c016496d98 100644
--- a/include/linux/qcom-geni-se.h
+++ b/include/linux/qcom-geni-se.h
@@ -77,6 +77,7 @@ struct geni_se {
#define SE_DMA_RX_FSM_RST 0xd58
#define SE_HW_PARAM_0 0xe24
#define SE_HW_PARAM_1 0xe28
+#define SE_DMA_DEBUG_REG0 0xe40
/* GENI_FORCE_DEFAULT_REG fields */
#define FORCE_DEFAULT BIT(0)
@@ -207,6 +208,10 @@ struct geni_se {
#define RX_GENI_CANCEL_IRQBIT(11)
#define RX_GENI_GP_IRQ_EXTGENMASK(13, 12)
+/* SE_DMA_DEBUG_REG0 Register fields */
+#define DMA_TX_ACTIVE BIT(0)
+#define DMA_RX_ACTIVE BIT(1)
+
/* SE_HW_PARAM_0 fields */
#define TX_FIFO_WIDTH_MSK GENMASK(29, 24)
#define TX_FIFO_WIDTH_SHFT24
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ingenic: Fix driver not probing when IPU port is missing
Hi Paul.
On Wed, Aug 26, 2020 at 11:58:41PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index ada990a7f911..216b67f1672e 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,6 +673,18 @@ static void ingenic_drm_unbind_all(void *d)
> component_unbind_all(priv->dev, &priv->drm);
> }
>
> +static inline struct device_node *ingenic_drm_get_ipu_node(struct device
> *dev)
> +{
> + /* IPU is at port address 8 */
> + return of_graph_get_remote_node(dev->of_node, 8, 0);
> +}
kernel-doc for of_graph_get_remote_node() says:
* Return: Remote device node associated with remote endpoint node linked
* to @node. Use of_node_put() on it when done.
In other words this code leaks a device node.
This was the case with the old code too.
Sam
> +
> +static inline bool ingenic_drm_has_ipu(struct device *dev)
> +{
> + return IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
> + !!ingenic_drm_get_ipu_node(dev);
> +}
> +
> static int ingenic_drm_bind(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> @@ -808,7 +820,7 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (ingenic_drm_has_ipu(dev)) {
> ret = component_bind_all(dev, drm);
> if (ret) {
> if (ret != -EPROBE_DEFER)
> @@ -970,12 +982,9 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
> if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
> return ingenic_drm_bind(dev);
>
> - /* IPU is at port address 8 */
> - np = of_graph_get_remote_node(dev->of_node, 8, 0);
> - if (!np) {
> - dev_err(dev, "Unable to get IPU node\n");
> - return -EINVAL;
> - }
> + np = ingenic_drm_get_ipu_node(dev);
> + if (!np)
> + return ingenic_drm_bind(dev);
>
> drm_of_component_match_add(dev, &match, compare_of, np);
>
> --
> 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Stefan,
Thank you for your review.
On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?
As far as I know, BCM2711 raspberry pi 4 supports 4k,
don't supported on pi 3 and pi 3+.
Since 4k is not supported in versions prior to Raspberry Pi 4,
I don't think we need to modify the bvb clock.
So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
instead of 'brcm,bcm2835-hdmi.yaml'.
Please comment, what do you think?
>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.
Tested it several times with libdrm modetest.
I expect there will be no problem.
Best regards,
Hoegeun
>
> Best regards
> Stefan
>
>> Signed-off-by: Hoegeun Kwon
>> ---
>> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>> # define VC4_HD_M_ENABLE BIT(0)
>>
>> #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>
>> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>> {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
>> drm_encoder *encoder)
>> HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>> clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
>> drm_encoder *encoder)
>> return;
>> }
>>
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> if (vc4_hdmi->variant->reset)
>> vc4_hdmi->variant->reset(vc4_hdmi);
>>
>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>> *vc4_hdmi)
>> return PTR_ERR(vc4_hdmi->audio_clock);
>> }
>>
>> +vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>> +if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>> +DRM_ERROR("Failed to get pixel bvb clock\n");
>> +return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>> +}
>> +
>> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>> if (IS_ERR(vc4_hdmi->reset)) {
>> DRM_ERROR("Failed to get HDMI reset line\n");
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> index 0806c6d9f24e..63c6f8bddf1d 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>> struct clk *pixel_clock;
>> struct clk *hsm_clock;
>> struct clk *audio_clock;
>> +struct clk *pixel_bvb_clock;
>>
>> struct reset_control *reset;
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vkms: avoid warning in vkms_get_vblank_timestamp
This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't
enabled. When running igt test kms_cursor_crc just after vkms module, the
warning raised like below. Initial value of vblank time is zero and
hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module
isn't real hardware but just virtual hardware module. so vkms can't generate a
resonable timestamp when hrtimer is off. it's best to grab the current time.
[106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change
[106444.471475] WARNING: CPU: 0 PID: 10109 at
/home/realwakka/git/linux/drivers/gpu/drm/vkms//vkms_crtc.c:91
vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: GW OE
5.9.0-rc1+ #6
[106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471528] Call Trace:
[106444.471551] drm_get_last_vbltimestamp+0xb9/0xd0 [drm]
[106444.471566] drm_reset_vblank_timestamp+0x63/0xe0 [drm]
[106444.471579] drm_crtc_vblank_on+0x85/0x150 [drm]
[106444.471582] vkms_crtc_atomic_enable+0xe/0x10 [vkms]
[106444.471592] drm_atomic_helper_commit_modeset_enables+0x1db/0x230
[drm_kms_helper]
[106444.471594] vkms_atomic_commit_tail+0x38/0xc0 [vkms]
[106444.471601] commit_tail+0x97/0x130 [drm_kms_helper]
[106444.471608] drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper]
[106444.471622] drm_atomic_commit+0x4a/0x50 [drm]
[106444.471629] drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper]
[106444.471642] drm_mode_setcrtc+0x1d9/0x7b0 [drm]
[106444.471654] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471666] drm_ioctl_kernel+0xb6/0x100 [drm]
[106444.471677] drm_ioctl+0x3ad/0x470 [drm]
[106444.471688] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471692] ? tomoyo_file_ioctl+0x19/0x20
[106444.471694] __x64_sys_ioctl+0x96/0xd0
[106444.471697] do_syscall_64+0x37/0x80
[106444.471699] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Sidong Yang
---
v2:
- modify commit message to make it a bit easier to understand.
---
drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..09c012d54d58 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
struct vkms_output *output = &vkmsdev->output;
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+ if (!READ_ONCE(vblank->enabled)) {
+ *vblank_time = ktime_get();
+ return true;
+ }
+
*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
if (WARN_ON(*vblank_time == vblank->time))
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209019] [drm:dpcd_set_source_specific_data [amdgpu]] *ERROR* Error in DP aux read transaction, not writing source specific data
https://bugzilla.kernel.org/show_bug.cgi?id=209019 --- Comment #7 from rtmasura+ker...@hotmail.com --- Created attachment 292183 --> https://bugzilla.kernel.org/attachment.cgi?id=292183&action=edit Xorg.0.log Found the second place for the log, let me know if it helps at all -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix warning in vkms_get_vblank_timestamp
On Wed, Aug 26, 2020 at 05:49:54PM -0300, Melissa Wen wrote:
Hi Melissa!
Thanks for review.
> Hi Sidong,
>
> Thanks for this patch.
>
> The code looks good to me; however, I see some issues in the patch
> format and commit message. Please, see inline comments.
>
> On 08/25, Sidong Yang wrote:
> > From: Sidong Yang , Haneen Mohammed
> >
>
> You need to fix the Author name.
Oops.
> >
> > When vkms_get_vblank_timestamp() is called very first time without
> > enabling vblank before, vblank time has just intial value and it makes
> > warning message. this patch prevents warning message by setting vblank
> > time to current time.
>
> I consider *fix* a somewhat strong term to this change. In my opinion,
> it would be better to choose another term in the commit message like
> *avoid* timestamp warning when vblanks aren't enabled.
It's good to me. Next patch need to be more explicit.
>
> In the body of the commit message, I think interesting to include the
> exactly warning message that this patch addresses. You could also
> describe the initial values that triggers this warning and why this
> approach is reasonable, as VKMS has fake clocks.
Yeah, It will be more comprehensive patch if there is description in detail.
I'll work for next patch!
Thanks.
-Sidong
>
> >
> > Cc: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Melissa Wen
> >
> > Signed-off-by: Sidong Yang
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..09c012d54d58 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc
> > *crtc,
> > struct vkms_output *output = &vkmsdev->output;
> > struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> >
> > + if (!READ_ONCE(vblank->enabled)) {
> > + *vblank_time = ktime_get();
> > + return true;
> > + }
> > +
>
> Apart from issues in commit message and format, I checked the code and it
> works fine.
>
> Reviewed-by: Melissa Wen
>
> > *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
> >
> > if (WARN_ON(*vblank_time == vblank->time))
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 628/1509] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:268:17: sparse: sparse: cast removes address space '' of expression
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: dff7bd1a712d1fa6fb6289e38de0769dc8b5d1b4
commit: 10be8791067fc672e44fcaa7afb886390909a0c0 [628/1509] drm/amdkfd: Support
Sienna_Cichlid KFD v4
config: x86_64-randconfig-s022-20200826 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 10be8791067fc672e44fcaa7afb886390909a0c0
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:268:17: sparse: sparse:
>> cast removes address space '' of expression
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c:270:17: sparse: sparse:
cast removes address space '' of expression
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 10be8791067fc672e44fcaa7afb886390909a0c0
vim +268 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
192
193 static int hqd_load_v10_3(struct kgd_dev *kgd, void *mqd, uint32_t
pipe_id,
194 uint32_t queue_id, uint32_t __user *wptr,
195 uint32_t wptr_shift, uint32_t wptr_mask,
196 struct mm_struct *mm)
197 {
198 struct amdgpu_device *adev = get_amdgpu_device(kgd);
199 struct v10_compute_mqd *m;
200 uint32_t *mqd_hqd;
201 uint32_t reg, hqd_base, data;
202
203 m = get_mqd(mqd);
204
205 pr_debug("Load hqd of pipe %d queue %d\n", pipe_id, queue_id);
206 acquire_queue(kgd, pipe_id, queue_id);
207
208 /* HIQ is set during driver init period with vmid set to 0*/
209 if (m->cp_hqd_vmid == 0) {
210 uint32_t value, mec, pipe;
211
212 mec = (pipe_id / adev->gfx.mec.num_pipe_per_mec) + 1;
213 pipe = (pipe_id % adev->gfx.mec.num_pipe_per_mec);
214
215 pr_debug("kfd: set HIQ, mec:%d, pipe:%d, queue:%d.\n",
216 mec, pipe, queue_id);
217 value = RREG32(SOC15_REG_OFFSET(GC, 0,
mmRLC_CP_SCHEDULERS));
218 value = REG_SET_FIELD(value, RLC_CP_SCHEDULERS,
scheduler1,
219 ((mec << 5) | (pipe << 3) | queue_id | 0x80));
220 WREG32(SOC15_REG_OFFSET(GC, 0, mmRLC_CP_SCHEDULERS),
value);
221 }
222
223 /* HQD registers extend from CP_MQD_BASE_ADDR to
CP_HQD_EOP_WPTR_MEM. */
224 mqd_hqd = &m->cp_mqd_base_addr_lo;
225 hqd_base = SOC15_REG_OFFSET(GC, 0, mmCP_MQD_BASE_ADDR);
226
227 for (reg = hqd_base;
228 reg <= SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_WPTR_HI); reg++)
229 WREG32(reg, mqd_hqd[reg - hqd_base]);
230
231
232 /* Activate doorbell logic before triggering WPTR poll. */
233 data = REG_SET_FIELD(m->cp_hqd_pq_doorbell_control,
234 CP_HQD_PQ_DOORBELL_CONTROL, DOORBELL_EN,
1);
235 WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL),
data);
236
237 if (wptr) {
238 /* Don't read wptr with get_user because the user
239 * context may not be accessible (if this function
240 * runs in a work queue). Instead trigger a one-shot
241 * polling read from memory in the CP. This assumes
242 * that wptr is GPU-accessible in the queue's VMID via
243 * ATC or SVM. WPTR==RPTR before starting the poll so
244 * the CP starts fetching new commands from the right
245 * place.
246 *
247 * Guessing a 64-bit WPTR from a 32-bit RPTR is a bit
248 * tricky. Assume that the queue didn't overflow. The
249 * number of valid bits in the 32-bit RPTR depends on
250 * the queue size. The remaining bits are taken from
251 * the saved 64-bit WPTR. If the WPTR wrapped, add the
252 * queue size.
253 */
254 uint32_t queue_size =
255 2 << REG_GET_FIELD(m->cp_hqd_pq_control,
256 CP_HQD_PQ_CONTROL,
QUEUE_SIZE);
257 uint64_t gues
Re: [PATCH] drm/tidss: Add prepare_fb to the plane helper funcs
Hi Gowtham,
Thank you for the patch.
On Wed, Aug 26, 2020 at 04:44:09PM +0300, Tomi Valkeinen wrote:
> From: Gowtham Tammana
>
> drm_gem_fb_prepare_fb() extracts fence and attaches to plane state.
> The fence info is needed if implicit fencing is used. Add this as
> prepare_fb function pointer to plane helper funcs.
>
> Signed-off-by: Gowtham Tammana
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/tidss/tidss_plane.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
> b/drivers/gpu/drm/tidss/tidss_plane.c
> index 43e72d0b2d84..35067ae674ea 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include "tidss_crtc.h"
> #include "tidss_dispc.h"
> @@ -150,6 +151,7 @@ static void drm_plane_destroy(struct drm_plane *plane)
> }
>
> static const struct drm_plane_helper_funcs tidss_plane_helper_funcs = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_check = tidss_plane_atomic_check,
> .atomic_update = tidss_plane_atomic_update,
> .atomic_disable = tidss_plane_atomic_disable,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave and Daniel, here goes the first pull request towards 5.10: As requested, the gem patches have been separated into a drm-intel/topic/drm-intel-gem-next that will be sent separately by the gem team later. Thanks, Rodrigo. drm-intel-next-2020-08-24-1: UAPI Changes: - Introduce a mechanism to extend execbuf2 (Lionel) - Add syncobj timeline support (Lionel) Driver Changes: - Limit stolen mem usage on the compressed frame buffer (Ville) - Some clean-up around display's cdclk (Ville) - Some DDI changes for better DP link training according to spec (Imre) - Provide the perf pmu.module (Chris) - Remove dobious Valleyview PCI IDs (Alexei) - Add new display power saving feature for gen12+ called HOBL (Jose) - Move SKL's clock gating w/a to skl_init_clock_gating() (Ville) - Rocket Lake display additions (Matt) - Selftest: temporarily downgrade on severity of frequency scaling tests (Chris) - Introduce a new display workaround for fixing FLR related issues on new PCH. (Jose) - Temporarily disable FBC on TGL. It was the culprit of random underruns. (Uma). - Copy default modparams to mock i915_device (Chris) - Add compiler paranoia for checking HWSP values (Chris) - Remove useless gen check before calling intel_rps_boost (Chris) - Fix a null pointer dereference (Chris) - Add a couple of missing i915_active_fini() (Chris) - Update TGL display power's bw_buddy table according to update spec (Matt) - Fix couple wrong return values (Tianjia) - Selftest: Avoid passing random 0 into ilog2 (George) - Many Tiger Lake display fixes and improvements for Type-C and DP compliance (Imre, Jose) - Start the addition of PSR2 selective fetch (Jose) - Update a few DMC and HuC firmware versions (Jose) - Add gen11+ w/a to fix underuns (Matt) - Fix cmd parser desc matching with mask (Mika) The following changes since commit 62975d27d647a40c58d3b96c29b911fc4f33c310: drm/ttm: revert "drm/ttm: make TT creation purely optional v3" (2020-08-12 13:26:28 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-08-24-1 for you to fetch changes up to ced026e959bec5046afa310d6474e147b6294da2: drm/i915: Update DRIVER_DATE to 20200824 (2020-08-24 14:26:38 -0400) UAPI Changes: - Introduce a mechanism to extend execbuf2 (Lionel) - Add syncobj timeline support (Lionel) Driver Changes: - Limit stolen mem usage on the compressed frame buffer (Ville) - Some clean-up around display's cdclk (Ville) - Some DDI changes for better DP link training according to spec (Imre) - Provide the perf pmu.module (Chris) - Remove dobious Valleyview PCI IDs (Alexei) - Add new display power saving feature for gen12+ called HOBL (Jose) - Move SKL's clock gating w/a to skl_init_clock_gating() (Ville) - Rocket Lake display additions (Matt) - Selftest: temporarily downgrade on severity of frequency scaling tests (Chris) - Introduce a new display workaround for fixing FLR related issues on new PCH. (Jose) - Temporarily disable FBC on TGL. It was the culprit of random underruns. (Uma). - Copy default modparams to mock i915_device (Chris) - Add compiler paranoia for checking HWSP values (Chris) - Remove useless gen check before calling intel_rps_boost (Chris) - Fix a null pointer dereference (Chris) - Add a couple of missing i915_active_fini() (Chris) - Update TGL display power's bw_buddy table according to update spec (Matt) - Fix couple wrong return values (Tianjia) - Selftest: Avoid passing random 0 into ilog2 (George) - Many Tiger Lake display fixes and improvements for Type-C and DP compliance (Imre, Jose) - Start the addition of PSR2 selective fetch (Jose) - Update a few DMC and HuC firmware versions (Jose) - Add gen11+ w/a to fix underuns (Matt) - Fix cmd parser desc matching with mask (Mika) Alexei Podtelezhnikov (1): drm/i915: Remove dubious Valleyview PCI IDs Chris Wilson (7): drm/i915: Provide the perf pmu.module drm/i915/selftests: Downgrade severity of CS/SRM frequency scaling tests drm/i915: Copy default modparams to mock i915_device drm/i915/selftests: Add compiler paranoia for checking HWSP values drm/i915: Remove gen check before calling intel_rps_boost drm/i915/display: Check for an LPSP encoder before dereferencing drm/i915: Add a couple of missing i915_active_fini() George Spelvin (1): drm/i915/selftests: Avoid passing a random 0 into ilog2 Imre Deak (4): drm/i915/ddi: Don't frob the DP link scramble disabling flag drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training drm/i915/tgl: Make sure TC-cold is blocked before enabling TC AUX power wells drm/i915/tgl: Fix TC-cold block/unblock sequence José Roberto de Souza (8): drm/i915/display: Implement HOBL drm/i915: Implement WA 14011294188 dr
Re: [PATCH] drm/bridge: tc358767: fix EDID memory leak
Hi Tomi, Thank you for the patch. On Wed, Aug 26, 2020 at 04:40:17PM +0300, Tomi Valkeinen wrote: > The current EDID allocated with drm_get_edid() is freed when the driver > gets a new EDID, but it is not freed when the driver is removed, causing > a leak. > > Free the EDID (if any) on driver remove. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/bridge/tc358767.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index c2777b226c75..dbb18a86beaf 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -1695,6 +1695,8 @@ static int tc_remove(struct i2c_client *client) > drm_bridge_remove(&tc->bridge); > drm_dp_aux_unregister(&tc->aux); > > + kfree(tc->edid); > + tc->edid is gone in drm-misc-next, problem solved already :-) > return 0; > } -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/mediatek: remove duplicate include
Hi, Wang Hai: Chun-Kuang Hu 於 2020年8月21日 週五 上午7:23寫道： > > Hi, Wang Hai: > > Wang Hai 於 2020年8月19日 週三 上午11:00寫道： > > > > Remove mtk_drm_ddp.h which is included more than once > > > > Reviewed-by: Chun-Kuang Hu > Applied to mediatek-drm-fixes [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes Regards, Chun-Kuang. > > Reported-by: Hulk Robot > > Signed-off-by: Wang Hai > > --- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > index 040a8f393fe2..a34fd805ce6d 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > @@ -27,7 +27,6 @@ > > > > #include "mtk_drm_crtc.h" > > #include "mtk_drm_ddp.h" > > -#include "mtk_drm_ddp.h" > > #include "mtk_drm_ddp_comp.h" > > #include "mtk_drm_drv.h" > > #include "mtk_drm_gem.h" > > -- > > 2.17.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
Hi, Jitao:
Chun-Kuang Hu 於 2020年8月18日 週二 下午10:45寫道：
>
> Hi, Jitao:
>
> Jitao Shi 於 2020年8月18日 週二 上午10:41寫道：
> >
> > On Tue, 2020-08-18 at 07:42 +0800, Chun-Kuang Hu wrote:
> > > Hi, Jitao:
> > >
> > > Jitao Shi 於 2020年8月17日 週一 下午9:07寫道：
> > > >
> > > > horizontal_backporch_byte should be hbp * bpp - hbp extra bytes.
> > > > So remove the wrong subtraction 10.
> > > >
> > > > Signed-off-by: Jitao Shi
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 9 -
> > > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > index 270bf22c98fe..5d031e634571 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > @@ -473,14 +473,13 @@ static void mtk_dsi_config_vdo_timing(struct
> > > > mtk_dsi *dsi)
> > > > horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp
> > > > - 10);
> > >
> > > So this subtraction 10 is correct?
> > >
> > > Regards,
> > > Chun-Kuang.
> > >
> >
> > Yes, It is right.
> >
> > In the cea861 and dmt spec the mini hsync is 40 pixels.
> > So the vm->hsync_len * dsi_tmp_buf_bpp >= 120 > 10
> >
>
> OK, so
>
> Reviewed-by: Chun-Kuang Hu
>
Applied to mediatek-drm-fixes [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
Regards,
Chun-Kuang.
> > Best Regards
> > jitao
> > > >
> > > > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > > > - horizontal_backporch_byte =
> > > > - (vm->hback_porch * dsi_tmp_buf_bpp - 10);
> > > > + horizontal_backporch_byte = vm->hback_porch *
> > > > dsi_tmp_buf_bpp;
> > > > else
> > > > - horizontal_backporch_byte = ((vm->hback_porch +
> > > > vm->hsync_len) *
> > > > - dsi_tmp_buf_bpp - 10);
> > > > + horizontal_backporch_byte = (vm->hback_porch +
> > > > vm->hsync_len) *
> > > > + dsi_tmp_buf_bpp;
> > > >
> > > > data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> > > > - timing->da_hs_zero + timing->da_hs_exit + 3;
> > > > + timing->da_hs_zero + timing->da_hs_exit;
> > > >
> > > > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > > if ((vm->hfront_porch + vm->hback_porch) *
> > > > dsi_tmp_buf_bpp >
> > > > --
> > > > 2.12.5
> > > > ___
> > > > Linux-mediatek mailing list
> > > > linux-media...@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] i915: POC use dynamic_debug_exec_queries to control pr_debugs in gvt
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_params.c: In function 'param_set_dyndbg':
>> drivers/gpu/drm/i915/i915_params.c:307:11: error: implicit declaration of
>> function 'dynamic_debug_exec_queries' [-Werror=implicit-function-declaration]
307 | chgct = dynamic_debug_exec_queries(query, "i915");
| ^~
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/1b9bcd2cceed427d96bc9bf4eae6619201d645d6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
git checkout 1b9bcd2cceed427d96bc9bf4eae6619201d645d6
vim +/dynamic_debug_exec_queries +307 drivers/gpu/drm/i915/i915_params.c
283
284 static int param_set_dyndbg(const char *instr, const struct
kernel_param *kp)
285 {
286 static unsigned long int old_val;
287 unsigned int val;
288 unsigned long int changes, result;
289 int rc, chgct = 0, totct = 0, bitpos;
290 char query[OUR_QUERY_SIZE];
291
292 rc = kstrtouint(instr, 0, &val);
293 if (rc) {
294 pr_err("set_dyndbg: failed\n");
295 return -EINVAL;
296 }
297 result = val;
298 pr_info("set_dyndbg: result:0x%lx from %s\n", result, instr);
299
300 changes = result ^ old_val;
301
302 for_each_set_bit(bitpos, &changes, NUM_CLASSES) {
303
304 sprintf(query, "format='^%s' %cp",
pr_debug_classes[bitpos],
305 test_bit(bitpos, &result) ? '+' : '-');
306
> 307 chgct = dynamic_debug_exec_queries(query, "i915");
308 totct += chgct;
309 pr_info("change ct:%d on format='%s'\n", chgct,
310 pr_debug_classes[bitpos]);
311 }
312 old_val = result;
313 pr_info("change ct:%d\n", totct);
314 return 0;
315 }
316 static int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
317 {
318 return scnprintf(buffer, PAGE_SIZE, "%u\n",
319 *((unsigned int *)kp->arg));
320 }
321 static const struct kernel_param_ops param_ops_dyndbg = {
322 .set = param_set_dyndbg,
323 .get = param_get_dyndbg,
324 };
325
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/crtc: add drmm_crtc_alloc_with_planes()
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a003-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_crtc.c:336:1: warning: all paths through this function
>> will call itself [-Winfinite-recursion]
{
^
1 warning generated.
#
https://github.com/0day-ci/linux/commit/236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
git checkout 236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23
vim +336 drivers/gpu/drm/drm_crtc.c
311
312 /**
313 * drm_crtc_init_with_planes - Initialise a new CRTC object with
314 *specified primary and cursor planes.
315 * @dev: DRM device
316 * @crtc: CRTC object to init
317 * @primary: Primary plane for CRTC
318 * @cursor: Cursor plane for CRTC
319 * @funcs: callbacks for the new CRTC
320 * @name: printf style format string for the CRTC name, or NULL for
default name
321 *
322 * Inits a new object created as base part of a driver crtc object.
Drivers
323 * should use this function instead of drm_crtc_init(), which is only
provided
324 * for backwards compatibility with drivers which do not yet support
universal
325 * planes). For really simple hardware which has only 1 plane look at
326 * drm_simple_display_pipe_init() instead.
327 *
328 * Returns:
329 * Zero on success, error code on failure.
330 */
331 int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc
*crtc,
332struct drm_plane *primary,
333struct drm_plane *cursor,
334const struct drm_crtc_funcs *funcs,
335const char *name, ...)
> 336 {
337 va_list ap;
338 int ret;
339
340 if (name)
341 va_start(ap, name);
342 ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
funcs,
343 name, ap);
344 if (name)
345 va_end(ap);
346
347 return ret;
348 }
349 EXPORT_SYMBOL(drm_crtc_init_with_planes);
350
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix warning in vkms_get_vblank_timestamp
Hi Sidong,
Thanks for this patch.
The code looks good to me; however, I see some issues in the patch
format and commit message. Please, see inline comments.
On 08/25, Sidong Yang wrote:
> From: Sidong Yang , Haneen Mohammed
>
You need to fix the Author name.
>
> When vkms_get_vblank_timestamp() is called very first time without
> enabling vblank before, vblank time has just intial value and it makes
> warning message. this patch prevents warning message by setting vblank
> time to current time.
I consider *fix* a somewhat strong term to this change. In my opinion,
it would be better to choose another term in the commit message like
*avoid* timestamp warning when vblanks aren't enabled.
In the body of the commit message, I think interesting to include the
exactly warning message that this patch addresses. You could also
describe the initial values that triggers this warning and why this
approach is reasonable, as VKMS has fake clocks.
>
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Melissa Wen
>
> Signed-off-by: Sidong Yang
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..09c012d54d58 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc
> *crtc,
> struct vkms_output *output = &vkmsdev->output;
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>
> + if (!READ_ONCE(vblank->enabled)) {
> + *vblank_time = ktime_get();
> + return true;
> + }
> +
Apart from issues in commit message and format, I checked the code and it
works fine.
Reviewed-by: Melissa Wen
> *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
>
> if (WARN_ON(*vblank_time == vblank->time))
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm-printk: POC caller of dynamic-debug-exec-queries
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.9-rc2
next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm64-randconfig-r002-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_print.c:30:
>> include/linux/dynamic_debug.h:196:3: error: implicit declaration of function
>> 'printk' [-Werror,-Wimplicit-function-declaration]
printk(KERN_WARNING "dyndbg param is supported only in "
^
>> include/linux/dynamic_debug.h:196:10: error: use of undeclared identifier
>> 'KERN_WARNING'
printk(KERN_WARNING "dyndbg param is supported only in "
^
In file included from drivers/gpu/drm/drm_print.c:31:
In file included from include/linux/io.h:11:
In file included from include/linux/bug.h:5:
In file included from arch/arm64/include/asm/bug.h:26:
In file included from include/asm-generic/bug.h:19:
In file included from include/linux/kernel.h:15:
include/linux/printk.h:171:5: error: conflicting types for 'printk'
int printk(const char *fmt, ...);
^
include/linux/dynamic_debug.h:196:3: note: previous implicit declaration is
here
printk(KERN_WARNING "dyndbg param is supported only in "
^
>> drivers/gpu/drm/drm_print.c:70:11: error: implicit declaration of function
>> 'dynamic_debug_exec_queries' [-Werror,-Wimplicit-function-declaration]
chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
^
4 errors generated.
#
https://github.com/0day-ci/linux/commit/ad959a93dccb8fe5deb5a7da3e22049779571b9b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
git checkout ad959a93dccb8fe5deb5a7da3e22049779571b9b
vim +/printk +196 include/linux/dynamic_debug.h
e9d376f0fa66bd6 Jason Baron 2009-02-05 190
b48420c1d3019ce Jim Cromie 2012-04-27 191 static inline int
ddebug_dyndbg_module_param_cb(char *param, char *val,
b48420c1d3019ce Jim Cromie 2012-04-27 192
const char *modname)
b48420c1d3019ce Jim Cromie 2012-04-27 193 {
b48420c1d3019ce Jim Cromie 2012-04-27 194 if (strstr(param, "dyndbg")) {
516cf1be07cf3ab Jim Cromie 2012-05-01 195 /* avoid pr_warn(),
which wants pr_fmt() fully defined */
516cf1be07cf3ab Jim Cromie 2012-05-01 @196 printk(KERN_WARNING
"dyndbg param is supported only in "
b48420c1d3019ce Jim Cromie 2012-04-27 197
"CONFIG_DYNAMIC_DEBUG builds\n");
b48420c1d3019ce Jim Cromie 2012-04-27 198 return 0; /* allow and
ignore */
b48420c1d3019ce Jim Cromie 2012-04-27 199 }
b48420c1d3019ce Jim Cromie 2012-04-27 200 return -EINVAL;
b48420c1d3019ce Jim Cromie 2012-04-27 201 }
b48420c1d3019ce Jim Cromie 2012-04-27 202
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.9
Hi Dave, Daniel, Fixes for 5.9. The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.9-2020-08-26 for you to fetch changes up to b67a468a4ccef593cd8df6a02ba3d167b77f0c81: drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init (2020-08-26 15:45:52 -0400) amd-drm-fixes-5.9-2020-08-26: amdgpu: - Misc display fixes - Backlight fixes - MPO fix for DCN1 - Fixes for Sienna Cichlid - Fixes for Navy Flounder - Vega SW CTF fixes - SMU fix for Raven - Fix a possible overflow in INFO ioctl - Gfx10 clockgating fix Alex Deucher (1): drm/amdgpu: Fix buffer overflow in INFO ioctl Alexander Monakov (1): drm/amd/display: use correct scale for actual_brightness Brandon Syu (1): drm/amd/display: Keep current gain when ABM disable immediately Dinghao Liu (1): drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init Evan Quan (4): drm/amd/pm: correct Vega10 swctf limit setting drm/amd/pm: correct Vega12 swctf limit setting drm/amd/pm: correct Vega20 swctf limit setting drm/amd/pm: correct the thermal alert temperature limit settings Furquan Shaikh (1): drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps Jaehyun Chung (1): drm/amd/display: Revert HDCP disable sequence change Jiansong Chen (5): drm/amd/pm: enable run_btc callback for sienna_cichlid drm/amd/pm: set VCN pg per instances drm/amdgpu/gfx10: refine mgcg setting drm/amdgpu: use MODE1 reset for navy_flounder by default drm/amdgpu: disable runtime pm for navy_flounder Nicholas Kazlauskas (2): drm/amd/display: Reject overlay plane configurations in multi-display scenarios drm/amd/powerplay: Fix hardmins not being sent to SMU for RV Samson Tam (1): drm/amd/display: Fix passive dongle mistaken as active dongle in EDID emulation Sung Lee (1): drm/amd/display: Send DISPLAY_OFF after power down on boot Tao Zhou (1): drm/amdgpu: add asd fw check before loading asd Tong Zhang (1): drm/amd/display: should check error using DC_OK Wayne Lin (1): drm/amd/display: Retry AUX write when fail occurs drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/nv.c| 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 93 -- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +- .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 10 +++ drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 8 +- drivers/gpu/drm/amd/display/dc/dc_stream.h | 2 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 53 +++- .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 8 ++ drivers/gpu/drm/amd/display/dc/inc/hw/clk_mgr.h| 2 + drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 9 +-- .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 22 ++--- .../gpu/drm/amd/powerplay/hwmgr/vega12_thermal.c | 21 ++--- .../gpu/drm/amd/powerplay/hwmgr/vega20_thermal.c | 21 ++--- drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c | 11 ++- 18 files changed, 164 insertions(+), 116 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209019] [drm:dpcd_set_source_specific_data [amdgpu]] *ERROR* Error in DP aux read transaction, not writing source specific data
https://bugzilla.kernel.org/show_bug.cgi?id=209019 --- Comment #6 from rtmasura+ker...@hotmail.com --- Hmm, new wire did not help. And it always recovers during shutdown of the kernel, so when it leaves graphical mode. I don't think that rules out hardware, though, so still testing. Also didn't realize they had backported the hack to the LTS kernel.. so it also is not ruled out. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/plane: add drmm_universal_plane_alloc()
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a003-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_plane.c:156:5: warning: no previous prototype for
>> function '__drm_universal_plane_init' [-Wmissing-prototypes]
int __drm_universal_plane_init(struct drm_device *dev, struct drm_plane
*plane,
^
drivers/gpu/drm/drm_plane.c:156:1: note: declare 'static' if the function is
not intended to be used outside of this translation unit
int __drm_universal_plane_init(struct drm_device *dev, struct drm_plane
*plane,
^
static
1 warning generated.
#
https://github.com/0day-ci/linux/commit/d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
git checkout d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
vim +/__drm_universal_plane_init +156 drivers/gpu/drm/drm_plane.c
155
> 156 int __drm_universal_plane_init(struct drm_device *dev, struct drm_plane
> *plane,
157 uint32_t possible_crtcs,
158 const struct drm_plane_funcs *funcs,
159 const uint32_t *formats, unsigned int
format_count,
160 const uint64_t *format_modifiers,
161 enum drm_plane_type type,
162 const char *name, va_list ap)
163 {
164 struct drm_mode_config *config = &dev->mode_config;
165 unsigned int format_modifier_count = 0;
166 int ret;
167
168 /* plane index is used with 32bit bitmasks */
169 if (WARN_ON(config->num_total_plane >= 32))
170 return -EINVAL;
171
172 WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
173 (!funcs->atomic_destroy_state ||
174 !funcs->atomic_duplicate_state));
175
176 ret = drm_mode_object_add(dev, &plane->base,
DRM_MODE_OBJECT_PLANE);
177 if (ret)
178 return ret;
179
180 drm_modeset_lock_init(&plane->mutex);
181
182 plane->base.properties = &plane->properties;
183 plane->dev = dev;
184 plane->funcs = funcs;
185 plane->format_types = kmalloc_array(format_count,
sizeof(uint32_t),
186 GFP_KERNEL);
187 if (!plane->format_types) {
188 DRM_DEBUG_KMS("out of memory when allocating plane\n");
189 drm_mode_object_unregister(dev, &plane->base);
190 return -ENOMEM;
191 }
192
193 /*
194 * First driver to need more than 64 formats needs to fix this.
Each
195 * format is encoded as a bit and the current code only
supports a u64.
196 */
197 if (WARN_ON(format_count > 64))
198 return -EINVAL;
199
200 if (format_modifiers) {
201 const uint64_t *temp_modifiers = format_modifiers;
202
203 while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
204 format_modifier_count++;
205 }
206
207 if (format_modifier_count)
208 config->allow_fb_modifiers = true;
209
210 plane->modifier_count = format_modifier_count;
211
Re: [PATCH 1/4] drm-printk: POC caller of dynamic-debug-exec-queries
Hi Jim,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master tegra-drm/drm/tegra/for-next
drm-tip/drm-tip linus/master v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: microblaze-randconfig-r006-20200826 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=microblaze
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_print.c:30:
include/linux/dynamic_debug.h: In function 'ddebug_dyndbg_module_param_cb':
>> include/linux/dynamic_debug.h:196:3: error: implicit declaration of function
>> 'printk'; did you mean 'bprintf'? [-Werror=implicit-function-declaration]
196 | printk(KERN_WARNING "dyndbg param is supported only in "
| ^~
| bprintf
>> include/linux/dynamic_debug.h:196:10: error: 'KERN_WARNING' undeclared
>> (first use in this function)
196 | printk(KERN_WARNING "dyndbg param is supported only in "
| ^~~~
include/linux/dynamic_debug.h:196:10: note: each undeclared identifier is
reported only once for each function it appears in
>> include/linux/dynamic_debug.h:196:22: error: expected ')' before string
>> constant
196 | printk(KERN_WARNING "dyndbg param is supported only in "
| ^
| )
In file included from include/linux/kernel.h:15,
from include/asm-generic/bug.h:19,
from ./arch/microblaze/include/generated/asm/bug.h:1,
from include/linux/bug.h:5,
from include/linux/io.h:11,
from drivers/gpu/drm/drm_print.c:31:
include/linux/printk.h: At top level:
>> include/linux/printk.h:171:5: error: conflicting types for 'printk'
171 | int printk(const char *fmt, ...);
| ^~
include/linux/printk.h:171:1: note: a parameter list with an ellipsis can't
match an empty parameter name list declaration
171 | int printk(const char *fmt, ...);
| ^~~
In file included from drivers/gpu/drm/drm_print.c:30:
include/linux/dynamic_debug.h:196:3: note: previous implicit declaration of
'printk' was here
196 | printk(KERN_WARNING "dyndbg param is supported only in "
| ^~
drivers/gpu/drm/drm_print.c: In function 'param_set_dyndbg':
>> drivers/gpu/drm/drm_print.c:70:11: error: implicit declaration of function
>> 'dynamic_debug_exec_queries' [-Werror=implicit-function-declaration]
70 | chgct = dynamic_debug_exec_queries("module=drm* +p", NULL);
| ^~
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/ad959a93dccb8fe5deb5a7da3e22049779571b9b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jim-Cromie/dyndbg-POC-use-dynamic_debug_exec_queries-in-DRM/20200827-010409
git checkout ad959a93dccb8fe5deb5a7da3e22049779571b9b
vim +196 include/linux/dynamic_debug.h
e9d376f0fa66bd6 Jason Baron 2009-02-05 190
b48420c1d3019ce Jim Cromie 2012-04-27 191 static inline int
ddebug_dyndbg_module_param_cb(char *param, char *val,
b48420c1d3019ce Jim Cromie 2012-04-27 192
const char *modname)
b48420c1d3019ce Jim Cromie 2012-04-27 193 {
b48420c1d3019ce Jim Cromie 2012-04-27 194 if (strstr(param, "dyndbg")) {
516cf1be07cf3ab Jim Cromie 2012-05-01 195 /* avoid pr_warn(),
which wants pr_fmt() fully defined */
516cf1be07cf3ab Jim Cromie 2012-05-01 @196 printk(KERN_WARNING
"dyndbg param is supported only in "
b48420c1d3019ce Jim Cromie 2012-04-27 197
"CONFIG_DYNAMIC_DEBUG builds\n");
b48420c1d3019ce Jim Cromie 2012-04-27 198 return 0; /* allow and
ignore */
b48420c1d3019ce Jim Cromie 2012-04-27 199 }
b
Re: [PATCH] docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option.
On Wed, 26 Aug 2020 23:47:31 +0500 Bilal Wasim wrote: > On Mon, 24 Aug 2020 19:51:55 +0500 > Bilal Wasim wrote: [...] > > Can this simple patch be merged? You sent it two days ago. During a major community conference. Please be patient, somebody will get to it when they have a chance. jonv ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling
Hi Enric.
On Wed, Aug 26, 2020 at 10:15:26AM +0200, Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> -> ps8640_bridge_get_edid
>
> Actually if the bridge pre_enable() function was not called before
> get_edid(), the driver will not be able to get the EDID properly and
> display will not work until a second get_edid() call is issued and if
> pre_enable() is called before. The side effect of this, for example, is
> that you see anything when `Frecon` starts, neither the splash screen,
> until the graphical session manager starts.
>
> To fix this we need to make sure that all we need is enabled before
> reading the EDID. This means the following:
>
> 1. If get_edid() is called before having the device powered we need to
>power on the device. In such case, the driver will power off again the
>device.
>
> 2. If get_edid() is called after having the device powered, all should
>just work. We added a powered flag in order to avoid recurrent calls
>to ps8640_bridge_poweron() and unneeded delays.
>
> 3. This seems to be specific for this device, but we need to make sure
>the panel is powered on before do a power on cycle on this device.
>Otherwise the device fails to retrieve the EDID.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
> 1 file changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 9f7b7a9c53c5..c5d76e209bda 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -65,6 +65,7 @@ struct ps8640 {
> struct regulator_bulk_data supplies[2];
> struct gpio_desc *gpio_reset;
> struct gpio_desc *gpio_powerdown;
> + bool powered;
> };
>
> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640
> *ps_bridge,
> return 0;
> }
>
> -static void ps8640_pre_enable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
> unsigned long timeout;
> int ret, status;
>
> + if (ps_bridge->powered)
> + return;
> +
> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
> ps_bridge->supplies);
> if (ret < 0) {
> @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
> goto err_regulators_disable;
> }
>
> + ps_bridge->powered = true;
> +
> return;
>
> err_regulators_disable:
> @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
> ps_bridge->supplies);
> }
>
> -static void ps8640_post_disable(struct drm_bridge *bridge)
> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
> {
> - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> int ret;
>
> - ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (!ps_bridge->powered)
> + return;
>
> gpiod_set_value(ps_bridge->gpio_reset, 1);
> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
> @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge
> *bridge)
>ps_bridge->supplies);
> if (ret < 0)
> DRM_ERROR("cannot disable regulators %d\n", ret);
> +
> + ps_bridge->powered = false;
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + int ret;
> +
> + ps8640_bridge_poweron(ps_bridge);
> +
> + ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + if (ret < 0)
> + ps8640_bridge_poweroff(ps_bridge);
> +}
The impleimentation of ps8640_bridge_poweron() versus
ps8640_bridge_poweroff() is confusing.
ps8640_bridge_poweron() includes ps8640_bridge_vdo_control(.., ENABLE),
but ps8640_bridge_poweroff() does not include
ps8640_bridge_vdo_control(..., DISABLE).
This is inconsistent and confusing. At least it was for me when
reviewing. Can this be improved - or maybe just use naming that does not
indicate they are the reverse of each other?
> +
> +static void ps8640_post_disable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +
> + ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> + ps8640_bridge_poweroff(ps_bridge);
> }
>
> static int ps8640_bridge_attach(struct drm_bridge *bridge,
> @@ -24
[PATCH v5 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As a result, plugging in a dongle without anything
plugged into it currently results in a bogus EDID retrieval error in the kernel
log.
Additionally, most dongles won't send another long HPD signal if the
user suddenly plugs something in, they'll only send a short HPD IRQ with
the expectation that the source will check the sink count and reprobe
the connector if it's changed - something we don't actually do. As a
result, nothing will happen if the user plugs the dongle in before
plugging something into the dongle.
So, let's fix this by checking the sink count in both
nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the
connector if things change.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 53 ---
drivers/gpu/drm/nouveau/nouveau_encoder.h | 2 +
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index ad852e572cfec..59be357b17e00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,12 +36,21 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream
(default: enabled)");
static int nouveau_mst = 1;
module_param_named(mst, nouveau_mst, int, 0400);
+static bool
+nouveau_dp_has_sink_count(struct drm_connector *connector,
+ struct nouveau_encoder *outp)
+{
+ return drm_dp_read_sink_count_cap(connector, outp->dp.dpcd,
&outp->dp.desc);
+}
+
static enum drm_connector_status
nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
struct nouveau_encoder *outp)
{
+ struct drm_connector *connector = &nv_connector->base;
struct drm_dp_aux *aux = &nv_connector->aux;
struct nv50_mstm *mstm = NULL;
+ enum drm_connector_status status = connector_status_disconnected;
int ret;
u8 *dpcd = outp->dp.dpcd;
@@ -50,9 +59,9 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
ret = drm_dp_read_desc(aux, &outp->dp.desc,
drm_dp_is_branch(dpcd));
if (ret < 0)
- return connector_status_disconnected;
+ goto out;
} else {
- return connector_status_disconnected;
+ goto out;
}
if (nouveau_mst) {
@@ -61,12 +70,33 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
+ if (nouveau_dp_has_sink_count(connector, outp)) {
+ ret = drm_dp_read_sink_count(aux);
+ if (ret < 0)
+ goto out;
+
+ outp->dp.sink_count = ret;
+
+ /*
+* Dongle connected, but no display. Don't bother reading
+* downstream port info
+*/
+ if (!outp->dp.sink_count)
+ return connector_status_disconnected;
+ }
+
ret = drm_dp_read_downstream_info(aux, dpcd,
outp->dp.downstream_ports);
if (ret < 0)
- return connector_status_disconnected;
+ goto out;
- return connector_status_connected;
+ status = connector_status_connected;
+out:
+ if (status != connector_status_connected) {
+ /* Clear any cached info */
+ outp->dp.sink_count = 0;
+ }
+ return status;
}
int
@@ -159,6 +189,8 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
struct drm_connector *connector = &nv_connector->base;
struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP);
struct nv50_mstm *mstm;
+ int ret;
+ bool send_hpd = false;
if (!outp)
return;
@@ -170,12 +202,23 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
if (mstm && mstm->is_mst) {
if (!nv50_mstm_service(drm, nv_connector, mstm))
- nouveau_connector_hpd(connector);
+ send_hpd = true;
} else {
drm_dp_cec_irq(&nv_connector->aux);
+
+ if (nouveau_dp_has_sink_count(connector, outp)) {
+ ret = drm_dp_read_sink_count(&nv_connector->aux);
+ if (ret != outp->dp.sink_count)
+ send_hpd = true;
+ if (ret >= 0)
+ outp->dp.sink_count = ret;
+ }
}
mutex_unlock(&outp->dp.hpd_irq_lock);
+
+ if (send_hpd)
+
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
> if (s.sgp) {
> .
> """
> at location [1].
> but it doens't fix the problem.
>
> You're right though, this change does need to be made, this code
> doesn't handle pages of sg_dma_len(sg) == 0 correctly
> So my guess is that we have more bugs in other parts of the i915
> driver (or there is a problem with my "sg_dma_len == 0" fix above).
> I have been trying to spot where else the code might be buggy but I
> haven't had any luck so far.
>
> I'm doing a microconfernce (at LPC 2020) this wednesdays [1] on this
> if you're interested in attending.
> I'm hoping I can chat about it with a few people and find how can
> reproduce and fix this issues. I don't have any more time I can give
> to this unfortunately and it would be a shame for the work to go to
> waste.
>
> [0]
> https://github.com/torvalds/linux/blob/d012a7190fc1fd72ed48911e77ca97ba4521bccd/drivers/gpu/drm/i915/i915_scatterlist.h#L28
> [1] https://linuxplumbersconf.org/event/7/contributions/846/
>
> On Fri, 29 May 2020 at 22:21, Logan Gunthorpe wrote:
> >
> >
> >
> > On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> > > Patches are pending:
> > > https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/
> >
> > Cool, nice! Though, I still don't think that fixes the issue in
> > i915_scatterlist.h given it still ignores sg_dma_len() and strictly
> > relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
> > is the bug that got in Tom's way.
> >
> > >> However, as Robin pointed out, there are other ugly tricks like stopping
> > >> iterating through the SGL when sg_dma_len() is zero. For example, the
> > >> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> > >> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> > >> have complained by now seeing AMD has already switched to IOMMU-DMA.
We ran into the same issue with amdgpu and radeon when the AMD IOMMU
driver was converted and had to fix it as well. The relevant fixes
were:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42e67b479eab6d26459b80b4867298232b0435e7
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0199172f933342d8b1011aae2054a695c25726f4
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47f7826c520ecd92ffbffe59ecaa2fe61e42ec70
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0f83d164fb8f3a2b7bc379a6c1e27d1123a9eab
Alex
> > >
> > > I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> > > somewhere documented.
> >
> > Well whatever you want to call it, it is ugly to have some drivers doing
> > one thing with the returned value and others assuming there's an extra
> > zero at the end. It just causes confusion for people reading/copying the
> > code. It would be better if they are all consistent. However, I concede
> > stopping at zero should not be broken, presently.
> >
> > Logan
> ___
> 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
[PATCH v5 19/20] drm/i915/dp: Extract drm_dp_read_dpcd_caps()
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go ahead and just move
this code out of i915 into a shared DRM DP helper that we can use in
other drivers.
v2:
* Remove redundant dpcd[DP_DPCD_REV] == 0 check
* Fix drm_dp_dpcd_read() ret checks
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 77 +
drivers/gpu/drm/i915/display/intel_dp.c | 60 +---
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
include/drm/drm_dp_helper.h | 3 +
5 files changed, 83 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 46d88ef4f59ac..9ca88e6c78820 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -433,6 +433,83 @@ static u8 drm_dp_downstream_port_count(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
return port_count;
}
+static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 dpcd_ext[6];
+ int ret;
+
+ /*
+* Prior to DP1.3 the bit represented by
+* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
+* If it is set DP_DPCD_REV at h could be at a value less than
+* the true capability of the panel. The only way to check is to
+* then compare h and 2200h.
+*/
+ if (!(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
+ return 0;
+
+ ret = drm_dp_dpcd_read(aux, DP_DP13_DPCD_REV, &dpcd_ext,
+ sizeof(dpcd_ext));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(dpcd_ext))
+ return -EIO;
+
+ if (dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
+ DRM_DEBUG_KMS("%s: Extended DPCD rev less than base DPCD rev
(%d > %d)\n",
+ aux->name, dpcd[DP_DPCD_REV],
+ dpcd_ext[DP_DPCD_REV]);
+ return 0;
+ }
+
+ if (!memcmp(dpcd, dpcd_ext, sizeof(dpcd_ext)))
+ return 0;
+
+ DRM_DEBUG_KMS("%s: Base DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+ memcpy(dpcd, dpcd_ext, sizeof(dpcd_ext));
+
+ return 0;
+}
+
+/**
+ * drm_dp_read_dpcd_caps() - read DPCD caps and extended DPCD caps if
+ * available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: Buffer to store the resulting DPCD in
+ *
+ * Attempts to read the base DPCD caps for @aux. Additionally, this function
+ * checks for and reads the extended DPRX caps (%DP_DP13_DPCD_REV) if
+ * present.
+ *
+ * Returns: %0 if the DPCD was read successfully, negative error code
+ * otherwise.
+ */
+int drm_dp_read_dpcd_caps(struct drm_dp_aux *aux,
+ u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+ if (ret < 0)
+ return ret;
+ if (ret != DP_RECEIVER_CAP_SIZE || dpcd[DP_DPCD_REV] == 0)
+ return -EIO;
+
+ ret = drm_dp_read_extended_dpcd_caps(aux, dpcd);
+ if (ret < 0)
+ return ret;
+
+ DRM_DEBUG_KMS("%s: DPCD: %*ph\n",
+ aux->name, DP_RECEIVER_CAP_SIZE, dpcd);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_read_dpcd_caps);
+
/**
* drm_dp_read_downstream_info() - read DPCD downstream port info if available
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0de94fc6289be..284b15f845926 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,62 +4449,6 @@ intel_dp_link_down(struct intel_encoder *encoder,
}
}
-static void
-intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
-{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 dpcd_ext[6];
-
- /*
-* Prior to DP1.3 the bit represented by
-* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
-* if it is set DP_DPCD_REV at h could be at a value less than
-* the true capability of the panel. The only way to check is to
-* then compare h and 2200h.
-*/
- if (!(intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
- DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
- return;
-
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
-&dpcd_ext, sizeof(dpcd_ext)) != sizeof(dpcd_ext)) {
- drm_err(&i915->drm,
-
[PATCH v5 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 59be357b17e00..810bf69565683 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -54,15 +54,13 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
int ret;
u8 *dpcd = outp->dp.dpcd;
- ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
- if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
- ret = drm_dp_read_desc(aux, &outp->dp.desc,
- drm_dp_is_branch(dpcd));
- if (ret < 0)
- goto out;
- } else {
+ ret = drm_dp_read_dpcd_caps(aux, dpcd);
+ if (ret < 0)
+ goto out;
+
+ ret = drm_dp_read_desc(aux, &outp->dp.desc, drm_dp_is_branch(dpcd));
+ if (ret < 0)
goto out;
- }
if (nouveau_mst) {
mstm = outp->dp.mstm;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 10/20] drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..a5934064a75ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -44,7 +44,6 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
struct nv50_mstm *mstm = NULL;
int ret;
u8 *dpcd = outp->dp.dpcd;
- u8 tmp;
ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
if (ret == DP_RECEIVER_CAP_SIZE && dpcd[DP_DPCD_REV]) {
@@ -56,19 +55,10 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
*nv_connector,
return connector_status_disconnected;
}
- if (nouveau_mst)
+ if (nouveau_mst) {
mstm = outp->dp.mstm;
-
- if (mstm) {
- if (dpcd[DP_DPCD_REV] >= DP_DPCD_REV_12) {
- ret = drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &tmp);
- if (ret < 0)
- return connector_status_disconnected;
-
- mstm->can_mst = !!(tmp & DP_MST_CAP);
- } else {
- mstm->can_mst = false;
- }
+ if (mstm)
+ mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
return connector_status_connected;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 12/20] drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a connector hotplug happens to occur in parallel
with a modeset.
I haven't seen this actually happen yet, but since we're cleaning up
nouveau's hotplug handling code anyway and we already have a hpd worker,
we can simply fix this by only relying on the HPD worker to actually
reprobe connectors when we receive a HPD IRQ. We also add a mask to
nouveau_drm to keep track of which connectors are waiting to be reprobed
in response to an HPD IRQ.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 42 +
drivers/gpu/drm/nouveau/nouveau_connector.h | 1 +
drivers/gpu/drm/nouveau/nouveau_display.c | 70 ++---
drivers/gpu/drm/nouveau/nouveau_display.h | 1 +
drivers/gpu/drm/nouveau/nouveau_dp.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
7 files changed, 86 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 4a29f691c08e4..637e91594fbe8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1138,6 +1138,20 @@ nouveau_connector_funcs_lvds = {
.early_unregister = nouveau_connector_early_unregister,
};
+void
+nouveau_connector_hpd(struct drm_connector *connector)
+{
+ struct nouveau_drm *drm = nouveau_drm(connector->dev);
+ u32 mask = drm_connector_mask(connector);
+
+ mutex_lock(&drm->hpd_lock);
+ if (!(drm->hpd_pending & mask)) {
+ drm->hpd_pending |= mask;
+ schedule_work(&drm->hpd_work);
+ }
+ mutex_unlock(&drm->hpd_lock);
+}
+
static int
nouveau_connector_hotplug(struct nvif_notify *notify)
{
@@ -1147,8 +1161,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
struct drm_device *dev = connector->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
const struct nvif_notify_conn_rep_v0 *rep = notify->data;
- const char *name = connector->name;
- int ret;
bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
@@ -1156,31 +1168,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
return NVIF_NOTIFY_KEEP;
}
- ret = pm_runtime_get(drm->dev->dev);
- if (ret == 0) {
- /* We can't block here if there's a pending PM request
-* running, as we'll deadlock nouveau_display_fini() when it
-* calls nvif_put() on our nvif_notify struct. So, simply
-* defer the hotplug event until the device finishes resuming
-*/
- NV_DEBUG(drm, "Deferring HPD on %s until runtime resume\n",
-name);
- schedule_work(&drm->hpd_work);
-
- pm_runtime_put_noidle(drm->dev->dev);
- return NVIF_NOTIFY_KEEP;
- } else if (ret != 1 && ret != -EACCES) {
- NV_WARN(drm, "HPD on %s dropped due to RPM failure: %d\n",
- name, ret);
- return NVIF_NOTIFY_DROP;
- }
-
- NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
-
- drm_helper_hpd_irq_event(connector->dev);
+ NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", connector->name);
+ nouveau_connector_hpd(connector);
- pm_runtime_mark_last_busy(drm->dev->dev);
- pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_KEEP;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index d6de5cb8e2238..d0b859c4a80ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -187,6 +187,7 @@ nouveau_crtc_connector_get(struct nouveau_crtc *nv_crtc)
struct drm_connector *
nouveau_connector_create(struct drm_device *, const struct dcb_output *);
+void nouveau_connector_hpd(struct drm_connector *connector);
extern int nouveau_tv_disable;
extern int nouveau_ignorelid;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 13016769a194b..bceb48a2dfca6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -457,16 +457,70 @@ static struct nouveau_drm_prop_enum_list dither_depth[] =
{
} \
} while(0)
+void
+nouveau_display_hpd_resume(struct drm_device *dev)
+{
+ struct nouveau_drm *drm = nouveau_drm(dev);
+
+ mutex_lock(&drm->hpd_lock);
+
[PATCH v5 16/20] drm/i915/dp: Extract drm_dp_read_sink_count()
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_dpcd()
v5:
* Change name from drm_dp_get_sink_count() to drm_dp_read_sink_count()
* Also, add "See also:" section to kdocs
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 26 +
drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
include/drm/drm_dp_helper.h | 1 +
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 65ff21ae0c271..46d88ef4f59ac 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -733,6 +733,8 @@ EXPORT_SYMBOL(drm_dp_set_subconnector_property);
* @dpcd: A cached copy of the connector's DPCD RX capabilities
* @desc: A cached copy of the connector's DP descriptor
*
+ * See also: drm_dp_read_sink_count()
+ *
* Returns: %True if the (e)DP connector has a valid sink count that should
* be probed, %false otherwise.
*/
@@ -748,6 +750,30 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
+/**
+ * drm_dp_read_sink_count() - Retrieve the sink count for a given sink
+ * @aux: The DP AUX channel to use
+ *
+ * See also: drm_dp_read_sink_count_cap()
+ *
+ * Returns: The current sink count reported by @aux, or a negative error code
+ * otherwise.
+ */
+int drm_dp_read_sink_count(struct drm_dp_aux *aux)
+{
+ u8 count;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, &count);
+ if (ret < 0)
+ return ret;
+ if (ret != 1)
+ return -EIO;
+
+ return DP_GET_SINK_COUNT(count);
+}
+EXPORT_SYMBOL(drm_dp_read_sink_count);
+
/*
* I2C-over-AUX implementation
*/
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 38318ae935f88..0de94fc6289be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
+ int ret;
+
if (!intel_dp_read_dpcd(intel_dp))
return false;
@@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
if (intel_dp_has_sink_count(intel_dp)) {
- u8 count;
- ssize_t r;
-
- r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
- if (r < 1)
+ ret = drm_dp_read_sink_count(&intel_dp->aux);
+ if (ret < 0)
return false;
/*
@@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
* a member variable in intel_dp will track any changes
* between short pulse interrupts.
*/
- intel_dp->sink_count = DP_GET_SINK_COUNT(count);
+ intel_dp->sink_count = ret;
/*
* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4c56ce4dc54fc..bc5cb8c503fbc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1635,6 +1635,7 @@ struct drm_dp_desc;
bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const struct drm_dp_desc *desc);
+int drm_dp_read_sink_count(struct drm_dp_aux *aux);
void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
void drm_dp_aux_init(struct drm_dp_aux *aux);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 13/20] drm/i915/dp: Extract drm_dp_read_downstream_info()
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_read_downstream_info().
Note that when we do this, we also do make some functional changes while
we're at it:
* We always clear the downstream port info before trying to read it,
just to make things easier for the caller
* We skip reading downstream port info if the DPCD indicates that we
don't support downstream port info
* We only read as many bytes as needed for the reported number of
downstream ports, no sense in reading the whole thing every time
v2:
* Fixup logic for calculating the downstream port length to account for
the fact that downstream port caps can be either 1 byte or 4 bytes
long. We can actually skip fixing the max_clock/max_bpc helpers here
since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
* Fix ret code check for drm_dp_dpcd_read
v5:
* Change name from drm_dp_downstream_read_info() to
drm_dp_read_downstream_info()
* Also, add "See Also" sections for the various downstream info
functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(),
drm_dp_downstream_max_bpc())
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
squash! drm/i915/dp: Extract drm_dp_read_downstream_info()
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 62 -
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
include/drm/drm_dp_helper.h | 3 ++
3 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4c21cf69dad5a..f3643894ad951 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -423,6 +423,56 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
+static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 port_count = dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_PORT_COUNT_MASK;
+
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE &&
port_count > 4)
+ port_count = 4;
+
+ return port_count;
+}
+
+/**
+ * drm_dp_read_downstream_info() - read DPCD downstream port info if available
+ * @aux: DisplayPort AUX channel
+ * @dpcd: A cached copy of the port's DPCD
+ * @downstream_ports: buffer to store the downstream port info in
+ *
+ * See also:
+ * drm_dp_downstream_max_clock()
+ * drm_dp_downstream_max_bpc()
+ *
+ * Returns: 0 if either the downstream port info was read successfully or
+ * there was no downstream info to read, or a negative error code otherwise.
+ */
+int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS])
+{
+ int ret;
+ u8 len;
+
+ memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
+
+ /* No downstream info to read */
+ if (!drm_dp_is_branch(dpcd) ||
+ dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
+ !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return 0;
+
+ len = drm_dp_downstream_port_count(dpcd);
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
+ len *= 4;
+
+ ret = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, downstream_ports,
len);
+ if (ret < 0)
+ return ret;
+
+ return ret == len ? 0 : -EIO;
+}
+EXPORT_SYMBOL(drm_dp_read_downstream_info);
+
/**
* drm_dp_downstream_max_clock() - extract branch device max
* pixel rate for legacy VGA
@@ -431,7 +481,11 @@ EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
- * Returns max clock in kHz on success or 0 if max clock not defined
+ * See also:
+ * drm_dp_read_downstream_info()
+ * drm_dp_downstream_max_bpc()
+ *
+ * Returns: Max clock in kHz on success or 0 if max clock not defined
*/
int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4])
@@ -462,7 +516,11 @@ EXPORT_SYMBOL(drm_dp_downstream_max_clock);
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
- * Returns max bpc on success or 0 if max bpc not defined
+ * See also:
+ * drm_dp_read_downstream_info()
+ * drm_dp_downstream_max_clock()
+ *
+ * Returns: Max bpc on success or 0 if max bpc not defined
*/
int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4])
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4c7314b7a84e4..9c4b806af8c79 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/inte
[PATCH v5 06/20] drm/nouveau/kms: Search for encoders' connectors properly
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and
nv50_outp_get_new_connector().
v2:
* Don't line-wrap for_each_(old|new)_connector_in_state in
nv50_outp_get_(old|new)_connector() - sravn
v3:
* Fix potential uninitialized usage of nv_connector (needs to be
initialized to NULL at the start). Thanks kernel test robot!
v4:
* Actually fix uninitialized nv_connector usage in
nv50_audio_component_get_eld(). The previous fix wouldn't have worked
since we would have started out with nv_connector == NULL, but
wouldn't clear it after a single drm_for_each_encoder() iteration.
Thanks again Kernel bot!
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 18 +
drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 +
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 88 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14
drivers/gpu/drm/nouveau/nouveau_encoder.h | 6 +-
9 files changed, 105 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index ffdd447d87068..22d10f3285597 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -419,7 +419,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index f9f4482c79b54..42687ea2a4ca3 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -184,7 +184,8 @@ static bool nv04_dfp_mode_fixup(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
- struct nouveau_connector *nv_connector =
nouveau_encoder_connector_get(nv_encoder);
+ struct nouveau_connector *nv_connector =
+ nv04_encoder_get_connector(nv_encoder);
if (!nv_connector->native_mode ||
nv_connector->scaling_mode == DRM_MODE_SCALE_NONE ||
@@ -478,7 +479,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
helper->dpms(encoder, DRM_MODE_DPMS_ON);
NV_DEBUG(drm, "Output %s is running on CRTC %d using output %c\n",
-nouveau_encoder_connector_get(nv_encoder)->base.name,
+nv04_encoder_get_connector(nv_encoder)->base.name,
nv_crtc->index, '@' + ffs(nv_encoder->dcb->or));
}
@@ -591,7 +592,7 @@ static void nv04_dfp_restore(struct drm_encoder *encoder)
if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS) {
struct nouveau_connector *connector =
- nouveau_encoder_connector_get(nv_encoder);
+ nv04_encoder_get_connector(nv_encoder);
if (connector && connector->native_mode)
call_lvds_script(dev, nv_encoder->dcb, head,
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 900ab69df7e8f..3f046b917c85c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -35,6 +35,24 @@
#include
+struct nouveau_connector *
+nv04_encoder_get_connector(struct nouveau_encoder *encoder)
+{
+ struct drm_device *dev = to_drm_encoder(encoder)->dev;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+ struct nouveau_connector *nv_connector = NULL;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ if (connector->encoder == to_drm_encoder(encoder))
+ nv_connector = nouveau_connector(connector);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ return nv_connector;
+}
+
static void
nv04_display_fini(struct drm_device *dev, bool suspend)
{
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 495d3284e8766..5ace5e906949a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@
[PATCH v5 11/20] drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()
For whatever reason we currently unset the EDID for DP CEC support when responding to the connector being unplugged, instead of just doing it in nouveau_connector_detect() where we set the CEC EDID. This isn't really needed and could even potentially cause us to forget to unset the EDID if the connector is removed without a corresponding hpd event, so let's fix that. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_connector.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index b90591114faaf..4a29f691c08e4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -633,10 +633,11 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) conn_status = connector_status_connected; goto out; } - } out: + if (!nv_connector->edid) + drm_dp_cec_unset_edid(&nv_connector->aux); pm_runtime_mark_last_busy(dev->dev); pm_runtime_put_autosuspend(dev->dev); @@ -1174,8 +1175,6 @@ nouveau_connector_hotplug(struct nvif_notify *notify) return NVIF_NOTIFY_DROP; } - if (!plugged) - drm_dp_cec_unset_edid(&nv_connector->aux); NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name); drm_helper_hpd_irq_event(connector->dev); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 18/20] drm/nouveau/kms: Don't change EDID when it hasn't actually changed
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_property() actually checks
whether the new EDID we've specified is different from the previous one,
and updates the connector's epoch accordingly if it is. But, because we
always set the EDID to NULL first in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds() we end up making DRM think that the EDID
changes every single time we do a connector probe - which isn't needed.
So, let's fix this by not clearing the EDID at the start of the
connector probing process, and instead simply changing or removing it
once near the end of the probing process. This will help prevent us from
sending unneeded hotplug events to userspace when nothing has actually
changed.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 54 ++---
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 637e91594fbe8..49dd0cbc332ff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -528,6 +528,17 @@ nouveau_connector_set_encoder(struct drm_connector
*connector,
}
}
+static void
+nouveau_connector_set_edid(struct nouveau_connector *nv_connector,
+ struct edid *edid)
+{
+ struct edid *old_edid = nv_connector->edid;
+
+ drm_connector_update_edid_property(&nv_connector->base, edid);
+ kfree(old_edid);
+ nv_connector->edid = edid;
+}
+
static enum drm_connector_status
nouveau_connector_detect(struct drm_connector *connector, bool force)
{
@@ -541,13 +552,6 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
- /* Cleanup the previous EDID block. */
- if (nv_connector->edid) {
- drm_connector_update_edid_property(connector, NULL);
- kfree(nv_connector->edid);
- nv_connector->edid = NULL;
- }
-
/* Outputs are only polled while runtime active, so resuming the
* device here is unnecessary (and would deadlock upon runtime suspend
* because it waits for polling to finish). We do however, want to
@@ -560,22 +564,23 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0 && ret != -EACCES) {
pm_runtime_put_autosuspend(dev->dev);
+ nouveau_connector_set_edid(nv_connector, NULL);
return conn_status;
}
}
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
+ struct edid *new_edid;
+
if ((vga_switcheroo_handler_flags() &
VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
nv_connector->type == DCB_CONNECTOR_LVDS)
- nv_connector->edid = drm_get_edid_switcheroo(connector,
-i2c);
+ new_edid = drm_get_edid_switcheroo(connector, i2c);
else
- nv_connector->edid = drm_get_edid(connector, i2c);
+ new_edid = drm_get_edid(connector, i2c);
- drm_connector_update_edid_property(connector,
- nv_connector->edid);
+ nouveau_connector_set_edid(nv_connector, new_edid);
if (!nv_connector->edid) {
NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
connector->name);
@@ -609,6 +614,8 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
conn_status = connector_status_connected;
drm_dp_cec_set_edid(&nv_connector->aux, nv_connector->edid);
goto out;
+ } else {
+ nouveau_connector_set_edid(nv_connector, NULL);
}
nv_encoder = nouveau_connector_of_detect(connector);
@@ -652,18 +659,12 @@ nouveau_connector_detect_lvds(struct drm_connector
*connector, bool force)
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = NULL;
+ struct edid *edid = NULL;
enum drm_connector_status status = connector_status_disconnected;
- /* Cleanup the previous EDID block. */
- if (nv_connector->edid) {
- drm_
[PATCH v5 09/20] drm/i915/dp: Extract drm_dp_read_mst_cap()
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
v5:
* Drop !!()
* Move drm_dp_has_mst() out of header
* Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 3 +--
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e0..17dbed0a9800d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3486,6 +3486,28 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
dp_link_count)
return dp_link_bw * dp_link_count / 2;
}
+/**
+ * drm_dp_read_mst_cap() - check whether or not a sink supports MST
+ * @aux: The DP AUX channel to use
+ * @dpcd: A cached copy of the DPCD capabilities for this sink
+ *
+ * Returns: %True if the sink supports MST, %false otherwise
+ */
+bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
+const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 mstm_cap;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &mstm_cap) != 1)
+ return false;
+
+ return mstm_cap & DP_MST_CAP;
+}
+EXPORT_SYMBOL(drm_dp_read_mst_cap);
+
/**
* drm_dp_mst_topology_mgr_set_mst() - Set the MST state for a topology manager
* @mgr: manager to set state for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c0..4c7314b7a84e4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
}
-static bool
-intel_dp_sink_can_mst(struct intel_dp *intel_dp)
-{
- u8 mstm_cap;
-
- if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
- return false;
-
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_MSTM_CAP, &mstm_cap) != 1)
- return false;
-
- return mstm_cap & DP_MST_CAP;
-}
-
static bool
intel_dp_can_mst(struct intel_dp *intel_dp)
{
@@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
return i915->params.enable_dp_mst &&
intel_dp->can_mst &&
- intel_dp_sink_can_mst(intel_dp);
+ drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
}
static void
@@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder =
&dp_to_dig_port(intel_dp)->base;
- bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
+ bool sink_can_mst = drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
%s\n",
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 8b9eb4db3381c..6ae5860d8644e 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -728,10 +728,9 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
-
+bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool
mst_state);
-
int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
*handled);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 15/20] drm/i915/dp: Extract drm_dp_read_sink_count_cap()
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count() in
intel_dp_detect_dpcd(), which is a functional change.
v5:
* Change name from drm_dp_has_sink_count() to
drm_dp_read_sink_count_cap()
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
drivers/gpu/drm/i915/display/intel_dp.c | 21 -
include/drm/drm_dp_helper.h | 8 +++-
3 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f3643894ad951..65ff21ae0c271 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -726,6 +726,28 @@ void drm_dp_set_subconnector_property(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_dp_set_subconnector_property);
+/**
+ * drm_dp_read_sink_count_cap() - Check whether a given connector has a valid
sink
+ * count
+ * @connector: The DRM connector to check
+ * @dpcd: A cached copy of the connector's DPCD RX capabilities
+ * @desc: A cached copy of the connector's DP descriptor
+ *
+ * Returns: %True if the (e)DP connector has a valid sink count that should
+ * be probed, %false otherwise.
+ */
+bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const struct drm_dp_desc *desc)
+{
+ /* Some eDP panels don't set a valid value for the sink count */
+ return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
+ dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
+ dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
+ !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+}
+EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
+
/*
* I2C-over-AUX implementation
*/
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9c4b806af8c79..38318ae935f88 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4634,6 +4634,16 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
return true;
}
+static bool
+intel_dp_has_sink_count(struct intel_dp *intel_dp)
+{
+ if (!intel_dp->attached_connector)
+ return false;
+
+ return drm_dp_read_sink_count_cap(&intel_dp->attached_connector->base,
+ intel_dp->dpcd,
+ &intel_dp->desc);
+}
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
@@ -4653,13 +4663,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp_set_common_rates(intel_dp);
}
- /*
-* Some eDP panels do not set a valid value for sink count, that is why
-* it don't care about read it here and in intel_edp_init_dpcd().
-*/
- if (!intel_dp_is_edp(intel_dp) &&
- !drm_dp_has_quirk(&intel_dp->desc, 0,
- DP_DPCD_QUIRK_NO_SINK_COUNT)) {
+ if (intel_dp_has_sink_count(intel_dp)) {
u8 count;
ssize_t r;
@@ -5939,9 +5943,8 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
- if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
+ if (intel_dp_has_sink_count(intel_dp) &&
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-
return intel_dp->sink_count ?
connector_status_connected : connector_status_disconnected;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b8716b200666f..4c56ce4dc54fc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1631,6 +1631,11 @@ void drm_dp_set_subconnector_property(struct
drm_connector *connector,
const u8 *dpcd,
const u8 port_cap[4]);
+struct drm_dp_desc;
+bool drm_dp_read_sink_count_cap(struct drm_connector *connector,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const struct drm_dp_desc *desc);
+
void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
void drm_dp_aux_init(struct drm_dp_aux *aux);
int drm_dp_aux_register(struct drm_dp_aux *aux);
@@ -1689,7 +1694,8 @@ enum drm_dp_quirk {
* @DP_DPCD_QUIRK_NO_SINK_COUNT:
*
* The device does not set SINK_COUNT to a non-zero value.
-* The driver should ignore SINK_COUNT during detection.
+* The driver should ignore SINK_COUNT during detection. Note that
+* drm_dp_read_sink_count_cap(
[PATCH v5 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, since we wouldn't be able to do anything without
DPCD access anyway.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +++
drivers/gpu/drm/nouveau/nouveau_dp.c | 15 +++
drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 8e1effb10425d..d2141ca16107b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1258,7 +1258,10 @@ nv50_mstc_detect(struct drm_connector *connector,
ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
mstc->port);
+ if (ret != connector_status_connected)
+ goto out;
+out:
pm_runtime_mark_last_busy(connector->dev->dev);
pm_runtime_put_autosuspend(connector->dev->dev);
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 005750aeb6d4f..ad852e572cfec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector *nv_connector,
mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
}
+ ret = drm_dp_read_downstream_info(aux, dpcd,
+ outp->dp.downstream_ports);
+ if (ret < 0)
+ return connector_status_disconnected;
+
return connector_status_connected;
}
@@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
/* TODO:
* - Use the minimum possible BPC here, once we add support for the max bpc
* property.
- * - Validate the mode against downstream port caps (see
- * drm_dp_downstream_max_clock())
* - Validate against the DP caps advertised by the GPU (we don't check these
* yet)
*/
@@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector,
unsigned *out_clock)
{
const unsigned min_clock = 25000;
- unsigned max_clock, clock;
+ unsigned max_clock, ds_clock, clock;
enum drm_mode_status ret;
if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = outp->dp.link_nr * outp->dp.link_bw;
- clock = mode->clock * (connector->display_info.bpc * 3) / 10;
+ ds_clock = drm_dp_downstream_max_clock(outp->dp.dpcd,
+ outp->dp.downstream_ports);
+ if (ds_clock)
+ max_clock = min(max_clock, ds_clock);
+ clock = mode->clock * (connector->display_info.bpc * 3) / 10;
ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
&clock);
if (out_clock)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index eef4643f5f982..c1924a4529a7b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -72,6 +72,7 @@ struct nouveau_encoder {
struct mutex hpd_irq_lock;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
+ u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct drm_dp_desc desc;
} dp;
};
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/20] drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I did this piggy-backing with the
intention that I'd eventually be teaching our MST helpers how to recover
when an MST device has stopped responding, which in turn would require
the MST helpers having a way of disabling MST independently of the
driver. Note that this was before I reworked locking in the MST helpers,
so at the time we were sticking random things under &mgr->lock - which
grabbing this lock was meant to protect against.
This never came to fruition because doing such a reset safely turned out
to be a lot more painful and impossible then it sounds, and also just
risks us working around issues with our MST handlers that should be
properly fixed instead. Even if it did though, simply calling
drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the
exception of when we're tearing down our MST managers, that's always OK)
wouldn't have been a bad idea, since drivers like nouveau and i915 need
to do their own book keeping immediately after disabling MST.
So-implementing that would likely require adding a hook for
helper-triggered MST disables anyway.
So, fast forward to now - we want to start adding support for all of the
miscellaneous bits of the DP protocol (for both SST and MST) we're
missing before moving on to supporting more complicated features like
supporting different BPP values on MST, DSC, etc. Since many of these
features only exist on SST and make use of DP HPD IRQs, we want to be
able to atomically check whether we're servicing an MST IRQ or SST IRQ
in nouveau_connector_hotplug(). Currently we literally don't do this at
all, and just handle any kind of possible DP IRQ we could get including
ESIs - even if MST isn't actually enabled.
This would be very complicated and difficult to fix if we need to hold
&mgr->lock while handling SST IRQs to ensure that the MST topology
state doesn't change under us. What we really want here is to do our own
tracking of whether MST is enabled or not, similar to drivers like i915,
and define our own locking order to decomplicate things and avoid
hitting locking issues in the future.
So, let's do this by refactoring our MST probing/enabling code to use
our own MST bookkeeping, along with adding a lock for protecting DP
state that needs to be checked outside of our connector probing
functions. While we're at it, we also remove a bunch of unneeded steps
we perform when probing/enabling MST:
* Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst().
I don't think these ever actually did anything, since the nvif methods
for enabling MST don't actually do anything DPCD related and merely
indicate to nvkm that we've turned on MST.
* Checking the MSTM_CTRL bit is intact when checking the state of an
enabled MST topology in nv50_mstm_detect(). I just added this to be safe
originally, but now that we try reading the DPCD when probing DP
connectors it shouldn't be needed as that will abort our hotplug probing
if the device was removed well before we start checking for MST..
* All of the duplicate DPCD version checks.
This leaves us with much nicer looking code, a much more sensible
locking scheme, and an easy way of checking whether MST is enabled or
not for handling DP HPD IRQs.
v2:
* Get rid of accidental newlines
v4:
* Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel
bot!
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 192 +---
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_dp.c| 132 --
drivers/gpu/drm/nouveau/nouveau_encoder.h | 33 +++-
7 files changed, 244 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 3f046b917c85c..3ee836dc5058f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -54,8 +54,9 @@ nv04_encoder_get_connector(struct nouveau_encoder *encoder)
}
static void
-nv04_display_fini(struct drm_device *dev, bool suspend)
+nv04_display_fini(struct drm_device *dev, bool runtime, bool suspend)
{
+ struct nouveau_drm *drm = nouveau_drm(dev);
struct nv04_display *disp = nv04_display(dev);
struct drm_crtc *crtc;
@@ -67,6 +68,9 @@ nv04_display_fini(struct drm_device *dev, bool suspend)
if (nv_two_heads(dev))
NVWriteCRTC(dev, 1, NV_PCRTC_INTR_EN_0, 0);
+ if (!runtime)
+ cancel_work_sync(&drm->hpd_work);
[PATCH v5 04/20] drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c
No functional changes. Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8db9216d52c69..4030806e3522b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -50,11 +50,13 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector, if (ret != sizeof(dpcd)) return ret; - nv_encoder->dp.link_bw = 27000 * dpcd[1]; - nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK; + nv_encoder->dp.link_bw = 27000 * dpcd[DP_MAX_LINK_RATE]; + nv_encoder->dp.link_nr = + dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK; NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, +dpcd[DP_DPCD_REV]); NV_DEBUG(drm, "encoder: %dx%d\n", nv_encoder->dcb->dpconf.link_nr, nv_encoder->dcb->dpconf.link_bw); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 03/20] drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index c4e9c21d4dd2b..8db9216d52c69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -42,16 +42,12 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
{
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_i2c_aux *aux;
- u8 dpcd[8];
+ struct drm_dp_aux *aux = &nv_connector->aux;
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
int ret;
- aux = nv_encoder->aux;
- if (!aux)
- return -ENODEV;
-
- ret = nvkm_rdaux(aux, DP_DPCD_REV, dpcd, sizeof(dpcd));
- if (ret)
+ ret = drm_dp_dpcd_read(aux, DP_DPCD_REV, dpcd, DP_RECEIVER_CAP_SIZE);
+ if (ret != sizeof(dpcd))
return ret;
nv_encoder->dp.link_bw = 27000 * dpcd[1];
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 07/20] drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable()
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 255a281249bc8..612d98fa0a2dc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1630,19 +1630,22 @@ nv50_sor_disable(struct drm_encoder *encoder,
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
+ struct nouveau_connector *nv_connector =
+ nv50_outp_get_old_connector(nv_encoder, state);
nv_encoder->crtc = NULL;
if (nv_crtc) {
- struct nvkm_i2c_aux *aux = nv_encoder->aux;
+ struct drm_dp_aux *aux = &nv_connector->aux;
u8 pwr;
- if (aux) {
- int ret = nvkm_rdaux(aux, DP_SET_POWER, &pwr, 1);
+ if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
+ int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
+
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
pwr |= DP_SET_POWER_D3;
- nvkm_wraux(aux, DP_SET_POWER, &pwr, 1);
+ drm_dp_dpcd_writeb(aux, DP_SET_POWER, pwr);
}
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/20] drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new()
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e7874877da858..c4d138f0ca054 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1535,17 +1535,6 @@ nv50_mstm_new(struct nouveau_encoder *outp, struct
drm_dp_aux *aux, int aux_max,
struct drm_device *dev = outp->base.base.dev;
struct nv50_mstm *mstm;
int ret;
- u8 dpcd;
-
- /* This is a workaround for some monitors not functioning
-* correctly in MST mode on initial module load. I think
-* some bad interaction with the VBIOS may be responsible.
-*
-* A good ol' off and on again seems to work here ;)
-*/
- ret = drm_dp_dpcd_readb(aux, DP_DPCD_REV, &dpcd);
- if (ret >= 0 && dpcd >= 0x12)
- drm_dp_dpcd_writeb(aux, DP_MSTM_CTRL, 0);
if (!(mstm = *pmstm = kzalloc(sizeof(*mstm), GFP_KERNEL)))
return -ENOMEM;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/20] drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_dp.c| 30 +++--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++-
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 7674025a4bfe8..e12957e6faa7c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -435,7 +435,8 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_DP:
- ret = nouveau_dp_detect(nv_encoder);
+ ret = nouveau_dp_detect(nouveau_connector(connector),
+ nv_encoder);
if (ret == NOUVEAU_DP_MST)
return NULL;
else if (ret == NOUVEAU_DP_SST)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index ee778ddc95fae..c4e9c21d4dd2b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -36,27 +36,9 @@ MODULE_PARM_DESC(mst, "Enable DisplayPort multi-stream
(default: enabled)");
static int nouveau_mst = 1;
module_param_named(mst, nouveau_mst, int, 0400);
-static void
-nouveau_dp_probe_oui(struct drm_device *dev, struct nvkm_i2c_aux *aux, u8
*dpcd)
-{
- struct nouveau_drm *drm = nouveau_drm(dev);
- u8 buf[3];
-
- if (!(dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
- return;
-
- if (!nvkm_rdaux(aux, DP_SINK_OUI, buf, 3))
- NV_DEBUG(drm, "Sink OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
- if (!nvkm_rdaux(aux, DP_BRANCH_OUI, buf, 3))
- NV_DEBUG(drm, "Branch OUI: %02hx%02hx%02hx\n",
-buf[0], buf[1], buf[2]);
-
-}
-
int
-nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
+nouveau_dp_detect(struct nouveau_connector *nv_connector,
+ struct nouveau_encoder *nv_encoder)
{
struct drm_device *dev = nv_encoder->base.base.dev;
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -89,7 +71,13 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
NV_DEBUG(drm, "maximum: %dx%d\n",
nv_encoder->dp.link_nr, nv_encoder->dp.link_bw);
- nouveau_dp_probe_oui(dev, aux, dpcd);
+ ret = drm_dp_read_desc(&nv_connector->aux, &nv_encoder->dp.desc,
+ drm_dp_is_branch(dpcd));
+ if (ret) {
+ NV_ERROR(drm, "Failed to read DP descriptor on %s: %d\n",
+nv_connector->base.name, ret);
+ return ret;
+ }
ret = nv50_mstm_detect(nv_encoder->dp.mstm, dpcd, nouveau_mst);
if (ret == 1)
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index a72c412ac8b14..6424cdcb4913f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -33,6 +33,7 @@
#include
#include "dispnv04/disp.h"
struct nv50_head_atom;
+struct nouveau_connector;
#define NV_DPMS_CLEARED 0x80
@@ -64,6 +65,7 @@ struct nouveau_encoder {
struct nv50_mstm *mstm;
int link_nr;
int link_bw;
+ struct drm_dp_desc desc;
} dp;
};
@@ -104,7 +106,7 @@ enum nouveau_dp_status {
NOUVEAU_DP_MST,
};
-int nouveau_dp_detect(struct nouveau_encoder *);
+int nouveau_dp_detect(struct nouveau_connector *, struct nouveau_encoder *);
enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
struct nouveau_encoder *,
const struct drm_display_mode *,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 00/20] drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code is just really unoptimized in general: * We handle connector probing in the same context that we handle short IRQs in for DP, which means connector probing could potentially block ESI handling for MST * When we receive a hotplug event from a connector, we reprobe every single connector instead of just the connector that was hotplugged * Additionally because of the above reason, combined with the fact I had the bad idea of reusing some of the MST locks when I last rewrote nouveau's DP MST detection, trying to handle any other events that require short HPD IRQs is a bit awkward to actually implement. * We don't actually properly check whether EDIDs change or not when reprobing, which means we basically send out a hotplug event every single time we receive one even if nothing has changed Additionally, the code for handling DP that we have in nouveau is also quite unoptimized in general, doesn't use a lot of helpers that have been added since it was written, and is also missing quite a number of features: * Downstream port capability probing * Extended DPRX cap parsing * SINK_COUNT handling for hpd on dongles Luckily for us - all of these are implemented in i915 already. Since there's no reason for us to reinvent the wheel, and having more shared code is always nice, I decided to take the opportunity to extract the code for all of these features from i915 into a set of core DP helpers, which both i915 and nouveau (and hopefully other drivers in the future) can use. As well, this patch series also addesses the other general connector probing related issues I mentioned above, along with rewriting how we handle MST probing so we don't hit any surprise locking design issues in the future. As a note - most of this work is motivated by the fact that I'm planning on adding max_bpc/output_bpc prop support, DSC support (for both MST and SST, along with proper helpers for handling bandwidth limitations and DSC), and fallback link retraining. I figured I might as clean this code up and implement missing DP features like the ones mentioned here before moving on to those tasks. Lyude Paul (20): drm/nouveau/kms: Fix some indenting in nouveau_dp_detect() drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc() drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new() drm/nouveau/kms: Search for encoders' connectors properly drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_read_mst_cap() drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_read_downstream_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_read_sink_count_cap() drm/i915/dp: Extract drm_dp_read_sink_count() drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT drm/nouveau/kms: Don't change EDID when it hasn't actually changed drm/i915/dp: Extract drm_dp_read_dpcd_caps() drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() drivers/gpu/drm/drm_dp_helper.c | 187 +++- drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++ drivers/gpu/drm/i915/display/intel_dp.c | 124 ++-- drivers/gpu/drm/i915/display/intel_dp.h | 1 - drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 24 +- drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 + drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 +++- drivers/gpu/drm/nouveau/nouveau_connector.c | 132 - drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 72 - drivers/gpu/drm/nouveau/nouveau_display.h | 3 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 210 +++--- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_encoder.h | 48 ++- include/drm/drm_dp_helper.h | 15 +- include/drm/drm
[PATCH v5 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -76,10 +76,10 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder) nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK; NV_DEBUG(drm, "display: %dx%d dpcd 0x%02x\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw, dpcd[0]); NV_DEBUG(drm, "encoder: %dx%d\n", -nv_encoder->dcb->dpconf.link_nr, -nv_encoder->dcb->dpconf.link_bw); +nv_encoder->dcb->dpconf.link_nr, +nv_encoder->dcb->dpconf.link_bw); if (nv_encoder->dcb->dpconf.link_nr < nv_encoder->dp.link_nr) nv_encoder->dp.link_nr = nv_encoder->dcb->dpconf.link_nr; @@ -87,7 +87,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder) nv_encoder->dp.link_bw = nv_encoder->dcb->dpconf.link_bw; NV_DEBUG(drm, "maximum: %dx%d\n", -nv_encoder->dp.link_nr, nv_encoder->dp.link_bw); +nv_encoder->dp.link_nr, nv_encoder->dp.link_bw); nouveau_dp_probe_oui(dev, aux, dpcd); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209019] [drm:dpcd_set_source_specific_data [amdgpu]] *ERROR* Error in DP aux read transaction, not writing source specific data
https://bugzilla.kernel.org/show_bug.cgi?id=209019 --- Comment #5 from rtmasura+ker...@hotmail.com --- Since I started getting this I was using the LTS kernel during the day because this is my work from home machine. I just had it happen with 5.4.60-1-lts. The virtual machine running on top of the machine IS using 5.8.2, but as this one does not have anything passed through other than USB devices, and the graphical display is spice, I think it's unlikely to be caused by the kernel. It's likely something else, so that means this ticket probably should be closed. I was one of the people bothered by https://bugzilla.kernel.org/show_bug.cgi?id=207383 and it was just suspicious that it began happening only after the upgrade to 5.8.1 which included the fix. As a troubleshooting step I disconnected power but not video, which caused the issue to remain. Only unplugging the video input stopped it. I've replaced the wire as a first troubleshooting step. If you have an idea what could cause it I'm all ears; right now I'll just assume hardware until I can rule it out. Thanks for your help. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Hi Tom, On 2019-12-21 15:03, Tom Murphy wrote: This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here: https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately. Could someone from the intel team look at this? I have been testing on a lenovo x1 carbon 5th generation. Let me know if there’s any more information you need. To allow my patch set to be tested I have added a patch (patch 8/8) in this series to disable combining sg segments in the dma-iommu api which fixes the bug but it doesn't fix the actual problem. As part of this patch series I copied the intel bounce buffer code to the dma-iommu path. The addition of the bounce buffer code took me by surprise. I did most of my development on this patch series before the bounce buffer code was added and my reimplementation in the dma-iommu path is very rushed and not properly tested but I’m running out of time to work on this patch set. On top of that I also didn’t port over the intel tracing code from this commit: https://github.com/torvalds/linux/commit/3b53034c268d550d9e8522e613a14ab53b8840d8#diff-6b3e7c4993f05e76331e463ab1fc87e1 So all the work in that commit is now wasted. The code will need to be removed and reimplemented in the dma-iommu path. I would like to take the time to do this but I really don’t have the time at the moment and I want to get these changes out before the iommu code changes any more. Further to what we just discussed at LPC, I've realised that tracepoints are actually something I could do with *right now* for debugging my Arm DMA ops series, so if I'm going to hack something up anyway I may as well take responsibility for polishing it into a proper patch as well :) Robin. Tom Murphy (8): iommu/vt-d: clean up 32bit si_domain assignment iommu/vt-d: Use default dma_direct_* mapping functions for direct mapped devices iommu/vt-d: Remove IOVA handling code from non-dma_ops path iommu: Handle freelists when using deferred flushing in iommu drivers iommu: Add iommu_dma_free_cpu_cached_iovas function iommu: allow the dma-iommu api to use bounce buffers iommu/vt-d: Convert intel iommu driver to the iommu ops DO NOT MERGE: iommu: disable list appending in dma-iommu drivers/iommu/Kconfig | 1 + drivers/iommu/amd_iommu.c | 14 +- drivers/iommu/arm-smmu-v3.c | 3 +- drivers/iommu/arm-smmu.c| 3 +- drivers/iommu/dma-iommu.c | 183 +-- drivers/iommu/exynos-iommu.c| 3 +- drivers/iommu/intel-iommu.c | 936 drivers/iommu/iommu.c | 39 +- drivers/iommu/ipmmu-vmsa.c | 3 +- drivers/iommu/msm_iommu.c | 3 +- drivers/iommu/mtk_iommu.c | 3 +- drivers/iommu/mtk_iommu_v1.c| 3 +- drivers/iommu/omap-iommu.c | 3 +- drivers/iommu/qcom_iommu.c | 3 +- drivers/iommu/rockchip-iommu.c | 3 +- drivers/iommu/s390-iommu.c | 3 +- drivers/iommu/tegra-gart.c | 3 +- drivers/iommu/tegra-smmu.c | 3 +- drivers/iommu/virtio-iommu.c| 3 +- drivers/vfio/vfio_iommu_type1.c | 2 +- include/linux/dma-iommu.h | 3 + include/linux/intel-iommu.h | 1 - include/linux/iommu.h | 32 +- 23 files changed, 345 insertions(+), 908 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/crtc: add drmm_crtc_alloc_with_planes()
Hi Philipp, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip linus/master v5.9-rc2 next-20200826] [cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: arm-randconfig-r001-20200826 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/gpu/drm/drm_crtc.c: In function '__drm_crtc_init_with_planes': >> drivers/gpu/drm/drm_crtc.c:267:3: warning: function >> '__drm_crtc_init_with_planes' might be a candidate for 'gnu_printf' format >> attribute [-Wsuggest-attribute=format] 267 | crtc->name = kvasprintf(GFP_KERNEL, name, ap); | ^~~~ # https://github.com/0day-ci/linux/commit/236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629 git checkout 236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23 vim +267 drivers/gpu/drm/drm_crtc.c 35f8cc3b9a92c66 Gustavo Padovan 2016-12-06 207 e954f77f6330028 Simon Ser 2020-05-21 208 /** e954f77f6330028 Simon Ser 2020-05-21 209 * DOC: standard CRTC properties e954f77f6330028 Simon Ser 2020-05-21 210 * e954f77f6330028 Simon Ser 2020-05-21 211 * DRM CRTCs have a few standardized properties: e954f77f6330028 Simon Ser 2020-05-21 212 * e954f77f6330028 Simon Ser 2020-05-21 213 * ACTIVE: e954f77f6330028 Simon Ser 2020-05-21 214 * Atomic property for setting the power state of the CRTC. When set to 1 e954f77f6330028 Simon Ser 2020-05-21 215 * the CRTC will actively display content. When set to 0 the CRTC will be e954f77f6330028 Simon Ser 2020-05-21 216 * powered off. There is no expectation that user-space will reset CRTC e954f77f6330028 Simon Ser 2020-05-21 217 * resources like the mode and planes when setting ACTIVE to 0. e954f77f6330028 Simon Ser 2020-05-21 218 * e954f77f6330028 Simon Ser 2020-05-21 219 * User-space can rely on an ACTIVE change to 1 to never fail an atomic e954f77f6330028 Simon Ser 2020-05-21 220 * test as long as no other property has changed. If a change to ACTIVE e954f77f6330028 Simon Ser 2020-05-21 221 * fails an atomic test, this is a driver bug. For this reason setting e954f77f6330028 Simon Ser 2020-05-21 222 * ACTIVE to 0 must not release internal resources (like reserved memory e954f77f6330028 Simon Ser 2020-05-21 223 * bandwidth or clock generators). e954f77f6330028 Simon Ser 2020-05-21 224 * e954f77f6330028 Simon Ser 2020-05-21 225 * Note that the legacy DPMS property on connectors is internally routed e954f77f6330028 Simon Ser 2020-05-21 226 * to control this property for atomic drivers. e954f77f6330028 Simon Ser 2020-05-21 227 * MODE_ID: e954f77f6330028 Simon Ser 2020-05-21 228 * Atomic property for setting the CRTC display timings. The value is the e954f77f6330028 Simon Ser 2020-05-21 229 * ID of a blob containing the DRM mode info. To disable the CRTC, e954f77f6330028 Simon Ser 2020-05-21 230 * user-space must set this property to 0. e954f77f6330028 Simon Ser 2020-05-21 231 * e954f77f6330028 Simon Ser 2020-05-21 232 * Setting MODE_ID to 0 will release reserved resources for the CRTC. e954f77f6330028 Simon Ser 2020-05-21 233 */ e954f77f6330028 Simon Ser 2020-05-21 234 236b7bc44ae0fde Philipp Zabel 2020-08-26 235 static int __drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc, e13161af80c185e Matt Roper 2014-04-01 236 struct drm_plane *primary, fc1d3e44ef7c1db Matt Roper 2014-06-10 237 st
Re: [v2] dma-buf: heaps: bugfix for selftest failure
Hi Leon, Shuah,
Thanks for the fix. I had this issue pending to fix,
but have been lazy about it, I appreciate you are taking care of it!
On Sat, 7 Mar 2020 at 11:03, Leon He wrote:
>
> From: Leon He
>
> There are two errors in the dmabuf-heap selftest:
> 1. The 'char name[5]' was not initialized to zero, which will cause
>strcmp(name, "vgem") failed in check_vgem().
> 2. The return value of test_alloc_errors() should be reversed, other-
>wise the while loop in main() will be broken.
>
> Signed-off-by: Leon He
> ---
> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> index cd5e1f6..836b185 100644
> --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -22,7 +22,7 @@
> static int check_vgem(int fd)
> {
> drm_version_t version = { 0 };
> - char name[5];
> + char name[5] = { 0 };
> int ret;
>
As Shuah already mentioned, I think we want to use strncmp
to be on the safe side.
> version.name_len = 4;
> @@ -357,7 +357,7 @@ static int test_alloc_errors(char *heap_name)
> if (heap_fd >= 0)
> close(heap_fd);
>
> - return ret;
> + return !ret;
I agree with Shuah, this change makes no sense, just drop it.
I think the fact this test was broken and nobody noticed
uncovers the fact that the test isn't being run.
Any reason why this test isn't a regular TARGET?
Or any idea how we can make sure this is run by CIs
and any other testing system?
Thanks!
Ezequiel
> }
>
> int main(void)
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tidss: Add prepare_fb to the plane helper funcs
From: Gowtham Tammana
drm_gem_fb_prepare_fb() extracts fence and attaches to plane state.
The fence info is needed if implicit fencing is used. Add this as
prepare_fb function pointer to plane helper funcs.
Signed-off-by: Gowtham Tammana
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
b/drivers/gpu/drm/tidss/tidss_plane.c
index 43e72d0b2d84..35067ae674ea 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "tidss_crtc.h"
#include "tidss_dispc.h"
@@ -150,6 +151,7 @@ static void drm_plane_destroy(struct drm_plane *plane)
}
static const struct drm_plane_helper_funcs tidss_plane_helper_funcs = {
+ .prepare_fb = drm_gem_fb_prepare_fb,
.atomic_check = tidss_plane_atomic_check,
.atomic_update = tidss_plane_atomic_update,
.atomic_disable = tidss_plane_atomic_disable,
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: tc358767: fix EDID memory leak
The current EDID allocated with drm_get_edid() is freed when the driver gets a new EDID, but it is not freed when the driver is removed, causing a leak. Free the EDID (if any) on driver remove. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/bridge/tc358767.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index c2777b226c75..dbb18a86beaf 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1695,6 +1695,8 @@ static int tc_remove(struct i2c_client *client) drm_bridge_remove(&tc->bridge); drm_dp_aux_unregister(&tc->aux); + kfree(tc->edid); + return 0; } -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] drm/bridge: ps8640: Make sure all needed is powered to get the EDID
Hi Enric On Wed, Aug 26, 2020 at 10:15:21AM +0200, Enric Balletbo i Serra wrote: > The first patch was initially part of the series [1] but for some reason > was not picked when the series were merged, so I included in this series > because it is needed to make the others to work properly. > > The same happened for the second patch, was part of series [1] but not > merged. > > The third patch and next are part of the original series and are to rework > the power handling to get the EDID. Basically, we need to make sure all the > needed is powered to be able to get the EDID. Before, we saw that getting > the EDID failed as explained in the third patch. > > [1] https://lkml.org/lkml/2020/6/15/1208 > > Changes in v2: > - Included the patch `drm/bridge_connector: Set default status connected for > eDP connectors` > - Included the patch `drm/bridge: ps8640: Get the EDID from eDP control` > - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg) > > Enric Balletbo i Serra (5): > drm/bridge_connector: Set default status connected for eDP connectors > drm/bridge: ps8640: Get the EDID from eDP control > drm/bridge: ps8640: Return an error for incorrect attach flags > drm/bridge: ps8640: Print an error if VDO control fails The first 4 patches are applied to drm-misc-next. > drm/bridge: ps8640: Rework power state handling Let give this a copuple of days on the mailing list to see what we conclude. Sam > > drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++ > drivers/gpu/drm/drm_bridge_connector.c | 1 + > 2 files changed, 79 insertions(+), 11 deletions(-) > > -- > 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
> > v2:
> > * Fix drm_dp_dpcd_readb() ret check
> > * Add back comment and move back sink_count assignment in
> > intel_dp_get_dpcd()
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 22 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
> > include/drm/drm_dp_helper.h | 1 +
> > 3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 863e0babc1903..67ad05eb05b7e 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector
> > *connector,
> > }
> > EXPORT_SYMBOL(drm_dp_has_sink_count);
> >
> > +/**
> > + * drm_dp_get_sink_count() - Retrieve the sink count for a given sink
>
> From the department of bikeshedding...
>
> Should we have a naming scheme where it's obvious whether a function
> will do DPCD access, or just shuffle existing data?
>
> For example, drm_dp_read_foo() for anything with DPCD access
> vs. drm_dp_get_foo() or even simpler for anything that only processes
> pre-read data?
Forgot to address this comment - yeah, I think that would be a good idea. I'll
go through my previous patches and make sure that they match this naming scheme
as well.
>
> > + * @aux: The DP AUX channel to use
> > + *
> > + * Returns: The current sink count reported by @aux, or a negative error
> > code
> > + * otherwise.
> > + */
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux)
> > +{
> > + u8 count;
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, &count);
> > + if (ret < 0)
> > + return ret;
> > + if (ret != 1)
> > + return -EIO;
>
> Makes me wonder if that shouldn't be at drm_dp_dpcd_read() level, for
> reads returning 0..len-1 bytes. Not necessarily part of this series, but
> seems silly to set a precedent to start handling that return value all
> over the place.
>
> BR,
> Jani.
>
> > +
> > + return DP_GET_SINK_COUNT(count);
> > +}
> > +EXPORT_SYMBOL(drm_dp_get_sink_count);
> > +
> > /*
> > * I2C-over-AUX implementation
> > */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 35a4779a442e2..4337321a3be4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> > static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > + int ret;
> > +
> > if (!intel_dp_read_dpcd(intel_dp))
> > return false;
> >
> > @@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > }
> >
> > if (intel_dp_has_sink_count(intel_dp)) {
> > - u8 count;
> > - ssize_t r;
> > -
> > - r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
> > - if (r < 1)
> > + ret = drm_dp_get_sink_count(&intel_dp->aux);
> > + if (ret < 0)
> > return false;
> >
> > /*
> > @@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > * a member variable in intel_dp will track any changes
> > * between short pulse interrupts.
> > */
> > - intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> > + intel_dp->sink_count = ret;
> >
> > /*
> > * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index a1413a531eaf4..0c141fc81aaa8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
> > bool drm_dp_has_sink_count(struct drm_connector *connector,
> >const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >const struct drm_dp_desc *desc);
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
> >
> > void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
> > void drm_dp_aux_init(struct drm_dp_aux *aux);
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
> > v2:
> > * Fix drm_dp_dpcd_readb() ret check
> > * Add back comment and move back sink_count assignment in
> > intel_dp_get_dpcd()
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 22 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
> > include/drm/drm_dp_helper.h | 1 +
> > 3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 863e0babc1903..67ad05eb05b7e 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector
> > *connector,
> > }
> > EXPORT_SYMBOL(drm_dp_has_sink_count);
> >
> > +/**
> > + * drm_dp_get_sink_count() - Retrieve the sink count for a given sink
>
> From the department of bikeshedding...
>
> Should we have a naming scheme where it's obvious whether a function
> will do DPCD access, or just shuffle existing data?
>
> For example, drm_dp_read_foo() for anything with DPCD access
> vs. drm_dp_get_foo() or even simpler for anything that only processes
> pre-read data?
>
> > + * @aux: The DP AUX channel to use
> > + *
> > + * Returns: The current sink count reported by @aux, or a negative error
> > code
> > + * otherwise.
> > + */
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux)
> > +{
> > + u8 count;
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, &count);
> > + if (ret < 0)
> > + return ret;
> > + if (ret != 1)
> > + return -EIO;
>
> Makes me wonder if that shouldn't be at drm_dp_dpcd_read() level, for
> reads returning 0..len-1 bytes. Not necessarily part of this series, but
> seems silly to set a precedent to start handling that return value all
> over the place.
>
Yeah definitely - I'm probably going to keep this code here for now, but I would
like to convert drm_dp_dpcd_readb/writeb() to just return 0 on success (all
bytes written, I've never once seen a situation where we got less bytes than we
read - it's always all or nothing) and negative error code on failure. I'll get
to that soon
> BR,
> Jani.
>
> > +
> > + return DP_GET_SINK_COUNT(count);
> > +}
> > +EXPORT_SYMBOL(drm_dp_get_sink_count);
> > +
> > /*
> > * I2C-over-AUX implementation
> > */
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 35a4779a442e2..4337321a3be4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
> > static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > + int ret;
> > +
> > if (!intel_dp_read_dpcd(intel_dp))
> > return false;
> >
> > @@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > }
> >
> > if (intel_dp_has_sink_count(intel_dp)) {
> > - u8 count;
> > - ssize_t r;
> > -
> > - r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
> > - if (r < 1)
> > + ret = drm_dp_get_sink_count(&intel_dp->aux);
> > + if (ret < 0)
> > return false;
> >
> > /*
> > @@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > * a member variable in intel_dp will track any changes
> > * between short pulse interrupts.
> > */
> > - intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> > + intel_dp->sink_count = ret;
> >
> > /*
> > * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index a1413a531eaf4..0c141fc81aaa8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
> > bool drm_dp_has_sink_count(struct drm_connector *connector,
> >const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >const struct drm_dp_desc *desc);
> > +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
> >
> > void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
> > void drm_dp_aux_init(struct drm_dp_aux *aux);
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/plane: add drmm_universal_plane_alloc()
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc2 next-20200826]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-randconfig-r001-20200826 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/drm_plane.c:156:5: warning: no previous prototype for
>> '__drm_universal_plane_init' [-Wmissing-prototypes]
156 | int __drm_universal_plane_init(struct drm_device *dev, struct
drm_plane *plane,
| ^~
drivers/gpu/drm/drm_plane.c: In function '__drm_universal_plane_init':
>> drivers/gpu/drm/drm_plane.c:223:3: warning: function
>> '__drm_universal_plane_init' might be a candidate for 'gnu_printf' format
>> attribute [-Wsuggest-attribute=format]
223 | plane->name = kvasprintf(GFP_KERNEL, name, ap);
| ^
#
https://github.com/0day-ci/linux/commit/d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
git checkout d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
vim +/__drm_universal_plane_init +156 drivers/gpu/drm/drm_plane.c
155
> 156 int __drm_universal_plane_init(struct drm_device *dev, struct drm_plane
> *plane,
157 uint32_t possible_crtcs,
158 const struct drm_plane_funcs *funcs,
159 const uint32_t *formats, unsigned int
format_count,
160 const uint64_t *format_modifiers,
161 enum drm_plane_type type,
162 const char *name, va_list ap)
163 {
164 struct drm_mode_config *config = &dev->mode_config;
165 unsigned int format_modifier_count = 0;
166 int ret;
167
168 /* plane index is used with 32bit bitmasks */
169 if (WARN_ON(config->num_total_plane >= 32))
170 return -EINVAL;
171
172 WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
173 (!funcs->atomic_destroy_state ||
174 !funcs->atomic_duplicate_state));
175
176 ret = drm_mode_object_add(dev, &plane->base,
DRM_MODE_OBJECT_PLANE);
177 if (ret)
178 return ret;
179
180 drm_modeset_lock_init(&plane->mutex);
181
182 plane->base.properties = &plane->properties;
183 plane->dev = dev;
184 plane->funcs = funcs;
185 plane->format_types = kmalloc_array(format_count,
sizeof(uint32_t),
186 GFP_KERNEL);
187 if (!plane->format_types) {
188 DRM_DEBUG_KMS("out of memory when allocating plane\n");
189 drm_mode_object_unregister(dev, &plane->base);
190 return -ENOMEM;
191 }
192
193 /*
194 * First driver to need more than 64 formats needs to fix this.
Each
195 * format is encoded as a bit and the current code only
supports a u64.
196 */
197 if (WARN_ON(format_count > 64))
198 return -EINVAL;
199
200 if (format_modifiers) {
201 const uint64_t *temp_modifiers = format_modifiers;
202
203 while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
204 format_modifier_count++;
205 }
206
207 if (format_modifier_count)
208 config->allow_fb_modifiers = true;
209
210 plane->modifier_count = format_modifier_count;
211 plane->modifiers = kmalloc_array(for
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> LSPCON only supports 8 bpc for RGB/YCbCr444.
>
> Set the correct bpp otherwise it renders blank screen.
Hmm. Does
git://github.com/vsyrjala/linux.git dp_downstream_ports_5
work?
Actually better make that dp_downstream_ports_5^^^ aka.
54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
converters") to avoid the experiments and hacks I have sitting on top.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index b781bf469644..c7a44fcaade8 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> *connector,
> crtc_state->port_clock /= 2;
> crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> crtc_state->lspcon_downsampling = true;
> - }
> + } else
> + crtc_state->pipe_bpp = 24;
> }
>
> static bool lspcon_probe(struct intel_lspcon *lspcon)
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the Novatek NT36672A display controller; Add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.9-rc1 based drm-misc-next on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Novatek nt36672a drm: panel: Add novatek nt36672a panel driver .../display/panel/novatek,nt36672a.yaml | 81 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ 5 files changed, 866 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Novatek NT36672a is a generic DSI IC that drives command and video mode
panels. Add the driver for it.
Right now adding support for some Poco F1 phones that have an LCD panel
from Tianma connected with this IC, with a resolution of 1080x2246 that
operates in DSI video mode.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate
vrefresh on demand. Update for it.
v5: Fixed review comments from Sam:
- rebased on top of drm-misc-next
remove return of drm_panel_add()
remove drm_panel_detach()
- renamed the panel driver file to reflect that this is a novatek
nt36672a display driver and not only for tianma panels.
Adjusted some internal names also to reflect the same.
- corrected changelog to add info about the generic Novatek DSI IC
- corrected compatible string accordingly
- removed pinctrl
- used drm_panel* API for prepare/unprepare/disable/remove
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++
4 files changed, 785 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..aeecade2d65f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8d97d07c5871..02600f12a063 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510
around the Novatek NT35510 display controller, such as some
Hydis panels.
+config DRM_PANEL_NOVATEK_NT36672A
+ tristate "Novatek NT36672A DSI 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 the panels built
+ around the Novatek NT36672A display controller, such as some
+ Tianma panels used in a few Xiaomi Poco F1 mobile phone.
+
config DRM_PANEL_NOVATEK_NT39016
tristate "Novatek NT39016 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 15a4e7752951..4a36eb45f670 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,6 +19,7 @@ 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
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
new file mode 100644
index ..3f0c18e46818
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -0,0 +1,767 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ *
+ * This driver is for the DSI interface to panels using the NT36672A display
driver IC
+ * from Novatek.
+ * Currently supported are the Tianma FHD+ panels found in some Xiaomi phones,
including
+ * some variants of the Poco F1 phone.
+ *
+ * Panels using the Novatek NT37762A IC should add appropriate configuration
per-panel and
+ * use this driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+sta
[PATCH v5 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support added for
this tianma fhd video mode panel.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
v5: renamed to novatek,nt36672a, since the binding is for the IC and not
the panel.
---
.../display/panel/novatek,nt36672a.yaml | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index ..7f8d1097bee0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: tianma,fhd-video
+ - const: novatek,nt36672a
+description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a
fallback.
+
+ reg: true
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,fhd-video", "novatek,nt36672a";
+reg = <0>;
+vddi0-supply = <&vreg_l14a_1p88>;
+vddpos-supply = <&lab>;
+vddneg-supply = <&ibb>;
+
+reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <&dsi0_out>;
+ };
+};
+ };
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/exynos: hdmi: Simplify with dev_err_probe()
On 26.08.2020 16:55, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andrzej Hajda Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/exynos: dsi: Simplify with dev_err_probe()
On 26.08.2020 16:55, Krzysztof Kozlowski wrote: > Common pattern of handling deferred probe can be simplified with > dev_err_probe(). Less code and also it prints the error value. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andrzej Hajda Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tc358767: fix EDID memory leak
On 26.08.2020 15:40, Tomi Valkeinen wrote: > The current EDID allocated with drm_get_edid() is freed when the driver > gets a new EDID, but it is not freed when the driver is removed, causing > a leak. > > Free the EDID (if any) on driver remove. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: replace deprecated functions in vkms_driver
gem_vm_ops and gem_free_object_unlocked function pointer is deprecated.
This patch replace these functions with drm_gem_object_funcs. And
functions used in drm_gem_object_funcs, vkms_gem_vm_ops and
vkms_gem_free_object, are not used other file but vkms_gem.c. So these
goes static functions. When creating vkms_gem_object, vkms_gem_funcs
is used for drm_gem_object.funcs.
Cc: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Melissa Wen
Signed-off-by: Sidong Yang
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
drivers/gpu/drm/vkms/vkms_drv.h | 4
drivers/gpu/drm/vkms/vkms_gem.c | 21 +++--
3 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 83dd5567de8b..a3a1ee1f77fb 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
.release= drm_release,
};
-static const struct vm_operations_struct vkms_gem_vm_ops = {
- .fault = vkms_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static void vkms_release(struct drm_device *dev)
{
struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
@@ -101,8 +95,6 @@ static struct drm_driver vkms_driver = {
.release= vkms_release,
.fops = &vkms_driver_fops,
.dumb_create= vkms_dumb_create,
- .gem_vm_ops = &vkms_gem_vm_ops,
- .gem_free_object_unlocked = vkms_gem_free_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = vkms_prime_import_sg_table,
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index f4036bb0b9a8..d7870755513c 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -117,13 +117,9 @@ struct drm_plane *vkms_plane_init(struct vkms_device
*vkmsdev,
enum drm_plane_type type, int index);
/* Gem stuff */
-vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
-
int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
-void vkms_gem_free_object(struct drm_gem_object *obj);
-
int vkms_gem_vmap(struct drm_gem_object *obj);
void vkms_gem_vunmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index a017fc59905e..9d58e29c1b8f 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -7,6 +7,20 @@
#include "vkms_drv.h"
+static vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
+static void vkms_gem_free_object(struct drm_gem_object *obj);
+
+static const struct vm_operations_struct vkms_gem_vm_ops = {
+ .fault = vkms_gem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static struct drm_gem_object_funcs vkms_gem_funcs = {
+ .free = vkms_gem_free_object,
+ .vm_ops = &vkms_gem_vm_ops
+};
+
static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
u64 size)
{
@@ -19,6 +33,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct
drm_device *dev,
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(dev, &obj->gem, size);
+ obj->gem.funcs = &vkms_gem_funcs;
+
if (ret) {
kfree(obj);
return ERR_PTR(ret);
@@ -29,7 +45,7 @@ static struct vkms_gem_object *__vkms_gem_create(struct
drm_device *dev,
return obj;
}
-void vkms_gem_free_object(struct drm_gem_object *obj)
+static void vkms_gem_free_object(struct drm_gem_object *obj)
{
struct vkms_gem_object *gem = container_of(obj, struct vkms_gem_object,
gem);
@@ -42,7 +58,7 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
kfree(gem);
}
-vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
+static vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct vkms_gem_object *obj = vma->vm_private_data;
@@ -97,6 +113,7 @@ vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
return ret;
}
+
static struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
struct drm_file *file,
u32 *handle,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/plane: add drmm_universal_plane_alloc()
Hi Philipp, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm-exynos/exynos-drm-next v5.9-rc2 next-20200826] [cannot apply to drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-s001-20200826 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-191-g10164920-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/drm_plane.c:156:5: sparse: sparse: symbol >> '__drm_universal_plane_init' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
