[PATCH] drm/bridge: Fix error handling in analogix_dp_probe
In the error handling path, the clk_prepare_enable() function
call should be balanced by a corresponding 'clk_disable_unprepare()'
call , as already done in the remove function.
Fixes: 3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to
bridge directory")
Signed-off-by: Miaoqian Lin
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index eb590fb8e8d0..2c0f582b4d32 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1698,7 +1698,10 @@ analogix_dp_probe(struct device *dev, struct
analogix_dp_plat_data *plat_data)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(dp->reg_base))
+ if (IS_ERR(dp->reg_base)) {
+ ret = PTR_ERR(dp->reg_base);
+ goto err_disable_clk;
+ }
return ERR_CAST(dp->reg_base);
dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
@@ -1711,7 +1714,8 @@ analogix_dp_probe(struct device *dev, struct
analogix_dp_plat_data *plat_data)
if (IS_ERR(dp->hpd_gpiod)) {
dev_err(dev, "error getting HDP GPIO: %ld\n",
PTR_ERR(dp->hpd_gpiod));
- return ERR_CAST(dp->hpd_gpiod);
+ ret = PTR_ERR(dp->hpd_gpiod);
+ goto err_disable_clk;
}
if (dp->hpd_gpiod) {
@@ -1731,7 +1735,8 @@ analogix_dp_probe(struct device *dev, struct
analogix_dp_plat_data *plat_data)
if (dp->irq == -ENXIO) {
dev_err(&pdev->dev, "failed to get irq\n");
- return ERR_PTR(-ENODEV);
+ ret = -ENODEV;
+ goto err_disable_clk;
}
ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
@@ -1740,11 +1745,15 @@ analogix_dp_probe(struct device *dev, struct
analogix_dp_plat_data *plat_data)
irq_flags, "analogix-dp", dp);
if (ret) {
dev_err(&pdev->dev, "failed to request irq\n");
- return ERR_PTR(ret);
+ goto err_disable_clk;
}
disable_irq(dp->irq);
return dp;
+
+err_disable_clk:
+ clk_disable_unprepare(dp->clock);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(analogix_dp_probe);
--
2.17.1
Re: [PATCH v3] drm: of: Properly try all possible cases for bridge/panel detection
On Fri 01 Apr 00:44 PDT 2022, Paul Kocialkowski wrote:
> Hi Bjorn,
>
> On Thu 31 Mar 22, 20:16, Bjorn Andersson wrote:
> > On Tue 29 Mar 06:27 PDT 2022, Paul Kocialkowski wrote:
> >
> > > While bridge/panel detection was initially relying on the usual
> > > port/ports-based of graph detection, it was recently changed to
> > > perform the lookup on any child node that is not port/ports
> > > instead when such a node is available, with no fallback on the
> > > usual way.
> > >
> > > This results in breaking detection when a child node is present
> > > but does not contain any panel or bridge node, even when the
> > > usual port/ports-based of graph is there.
> > >
> > > In order to support both situations properly, this commit reworks
> > > the logic to try both options and not just one of the two: it will
> > > only return -EPROBE_DEFER when both have failed.
> > >
> >
> > Thanks for your patch Paul, it fixed a regression on a device where I
> > have a eDP bridge with an of_graph and a aux-bus defined.
> >
> > But unfortunately it does not resolve the regression I have for the
> > USB based DisplayPort setup described below.
> >
> >
> > In the Qualcomm DisplayPort driver We're calling:
> >
> > devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
> >
> > and with the following DT snippet the behavior changed:
> >
> > displayport-controller@ae9 {
> > compatible = "qcom,sc8180x-dp";
> > ...
> >
> > operating-points-v2 = <&dp0_opp_table>;
> >
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > port@0 {
> > reg = <0>;
> > dp0_in: endpoint {
> > remote-endpoint = <&display_driver>;
> > };
> > };
> > };
> >
> > dp0_opp_table: opp-table {
> > ...;
> > };
> > };
> >
> > Prior to the introduction of 80253168dbfd ("drm: of: Lookup if child
> > node has panel or bridge") this would return -ENODEV, so we could
> > differentiate the case when we have a statically defined eDP panel from
> > that of a dynamically attached (over USB) DP panel.
> >
> > Prior to your change, above case without the opp-table node would have
> > still returned -ENODEV.
> >
> > But now this will just return -EPROBE_DEFER in both cases.
>
> Oh that's right, the -ENODEV case was just completely removed by my change.
> Initially this would happen if !of_graph_is_present or if the remote node
> doesn't exist.
>
> Now that we are also checking for child nodes, we can't just return -ENODEV
> when the graph or remote node is missing: we must also check that there is no
> child node that is a panel/bridge.
>
> For the graph remote case, we can reliabily return -EPROBE_DEFER when
> of_graph_is_present and the remote exists and of_device_is_available.
Right, if I have a of_graph port@1 which references something that isn't
available we can reliably claim this is -EPROBE_DEFER.
> Otherwise we can go for -ENODEV.
Are you suggesting that if we find a "port" or "ports" we return -ENODEV
if we didn't find the requested port@N?
> I think getting -EPROBE_DEFER at this point
> should stop the drm_of_find_panel_or_bridge process.
>
I think that makes sense, i.e. if we found an of_graph reference, but
it's not a panel yet.
> On the other hand for the child panel/bridge node case, I don't see how we
> can reliably distinguish between -EPROBE_DEFER and -ENODEV, because
> of_drm_find_panel and of_drm_find_bridge will behave the same if the child
> node is a not-yet-probed panel/bridge or a totally unrelated node.
> So I think we should always return -EPROBE_DEFER in that case.
>
> As a result you can't get -ENODEV if using the of graph while having any
> (unrelated) child node there, so your issue remains.
>
> Do you see any way we could make this work?
>
I'm afraid I don't have any good suggestions on determining if that
child node is a panel/bridge or something else.
> > I thought the appropriate method of referencing the dsi panel was to
> > actually reference that using the of_graph, even though it's a child of
> > the dsi controller - that's at least how we've done it in e.g. [1].
> > I find this to be much nicer than to just blindly define that all
> > children of any sort of display controller must be a bridge or a panel.
>
> Yes I totally agree. Given that using the child node directly apparently
> can't allow us to distinguish between -EPROBE_DEFER/-ENODEV I would be in
> favor of dropping this mechanism and going with explicit of graph in any case
> (even if it's a child node). I don't see any downside to this approach.
>
> What do yout think?
>
The explicit of_graph reference is a little bit clunky, but it's clear
and doesn't rely on "skipping" or only including names based on
particular names etc.
So I am in favour of reverting this back to the explicit reference.
Regards,
Bjorn
> Paul
>
> > [1]
> > https://git.kernel.o
Re: [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5
On Mon, Mar 21, 2022 at 2:59 PM Christian König
wrote:
>
> Instead of distingting between shared and exclusive fences specify
> the fence usage while adding fences.
>
> Rework all drivers to use this interface instead and deprecate the old one.
>
> v2: some kerneldoc comments suggested by Daniel
> v3: fix a missing case in radeon
> v4: rebase on nouveau changes, fix lockdep and temporary disable warning
> v5: more documentation updates
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c| 345 --
> drivers/dma-buf/st-dma-resv.c | 101 ++---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 10 +-
> drivers/gpu/drm/i915/gem/i915_gem_busy.c | 13 +-
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 5 +-
> drivers/gpu/drm/i915/i915_vma.c | 6 +-
> drivers/gpu/drm/lima/lima_gem.c | 2 +-
> drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +-
> drivers/gpu/drm/nouveau/nouveau_fence.c | 4 +-
> drivers/gpu/drm/qxl/qxl_release.c | 3 +-
> drivers/gpu/drm/radeon/radeon_object.c| 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +-
> drivers/gpu/drm/ttm/ttm_execbuf_util.c| 6 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 4 +-
> drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
> drivers/gpu/drm/vgem/vgem_fence.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 3 +-
> include/linux/dma-buf.h | 17 +-
> include/linux/dma-resv.h | 72 ++--
> 26 files changed, 276 insertions(+), 370 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index bb7b023c2d33..26257ba1527e 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -44,12 +44,12 @@
> /**
> * DOC: Reservation Object Overview
> *
> - * The reservation object provides a mechanism to manage shared and
> - * exclusive fences associated with a buffer. A reservation object
> - * can have attached one exclusive fence (normally associated with
> - * write operations) or N shared fences (read operations). The RCU
> - * mechanism is used to protect read access to fences from locked
> - * write-side updates.
> + * The reservation object provides a mechanism to manage a container of
> + * dma_fence object associated with a resource. A reservation object
> + * can have any number of fences attaches to it. Each fence carring an usage
> + * parameter determining how the operation represented by the fence is using
> the
> + * resource. The RCU mechanism is used to protect read access to fences from
> + * locked write-side updates.
> *
> * See struct dma_resv for more details.
> */
> @@ -57,29 +57,74 @@
> DEFINE_WD_CLASS(reservation_ww_class);
> EXPORT_SYMBOL(reservation_ww_class);
>
> +/* Mask for the lower fence pointer bits */
> +#define DMA_RESV_LIST_MASK 0x3
> +
> struct dma_resv_list {
> struct rcu_head rcu;
> - u32 shared_count, shared_max;
> - struct dma_fence __rcu *shared[];
> + u32 num_fences, max_fences;
> + struct dma_fence __rcu *table[];
> };
>
> +/**
> + * dma_resv_list_entry - extract fence and usage from a list entry
> + * @list: the list to extract and entry from
> + * @index: which entry we want
> + * @resv: optional dma_resv obj for lockdep check that the access is allowed
> + * @fence: the resulting fence
> + * @usage: the resulting usage
> + *
> + * Extract the fence and usage flags from an RCU protected entry in the list.
> + */
> +static void dma_resv_list_entry(struct dma_resv_list *list, unsigned int
> index,
> + struct dma_resv *resv, struct dma_fence
> **fence,
> + enum dma_resv_usage *usage)
> +{
> + long tmp;
> +
> + tmp = (long)rcu_dereference_check(list->table[index],
> + resv ? dma_resv_held(resv) : true);
> + *fence = (struct dma_fence *)(tmp & ~DMA_RESV_LIST_MASK);
> + if (usage)
> + *usage = tmp & DMA_RESV_LIST_MASK;
> +}
> +
> +/**
> + * dma_resv_list_set - set fence and usage at a specific index
> + * @list: the list to modify
> + * @index: where to make the change
> + * @fence: the fence to set
> + * @usage: the usage to set
> + *
> + * Set the fence and usage flags at the specific index in the list.
> + */
> +static void dma_resv_list_set(struct dma_resv_list *list,
> + unsigned int index,
> +
Re: [PATCH] video: fbdev: Prepare cleanup of powerpc's asm/prom.h
On 4/2/22 12:22, Christophe Leroy wrote: > powerpc's asm/prom.h brings some headers that it doesn't > need itself. > > In order to clean it up, first add missing headers in > users of asm/prom.h > > Signed-off-by: Christophe Leroy applied to fbdev tree. Thanks! Helge > --- > drivers/video/fbdev/aty/aty128fb.c | 1 - > drivers/video/fbdev/aty/atyfb_base.c | 1 - > drivers/video/fbdev/aty/radeon_pm.c| 1 - > drivers/video/fbdev/aty/radeonfb.h | 2 +- > drivers/video/fbdev/controlfb.c| 3 --- > drivers/video/fbdev/matrox/matroxfb_base.h | 1 - > drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 2 ++ > drivers/video/fbdev/platinumfb.c | 2 +- > drivers/video/fbdev/valkyriefb.c | 3 +-- > 9 files changed, 5 insertions(+), 11 deletions(-) > > diff --git a/drivers/video/fbdev/aty/aty128fb.c > b/drivers/video/fbdev/aty/aty128fb.c > index 6ff16d3132e5..b26c81233b6b 100644 > --- a/drivers/video/fbdev/aty/aty128fb.c > +++ b/drivers/video/fbdev/aty/aty128fb.c > @@ -68,7 +68,6 @@ > #ifdef CONFIG_PPC_PMAC > #include > #include > -#include > #include "../macmodes.h" > #endif > > diff --git a/drivers/video/fbdev/aty/atyfb_base.c > b/drivers/video/fbdev/aty/atyfb_base.c > index 1aef3d6ebd88..a3e6faed7745 100644 > --- a/drivers/video/fbdev/aty/atyfb_base.c > +++ b/drivers/video/fbdev/aty/atyfb_base.c > @@ -79,7 +79,6 @@ > > #ifdef __powerpc__ > #include > -#include > #include "../macmodes.h" > #endif > #ifdef __sparc__ > diff --git a/drivers/video/fbdev/aty/radeon_pm.c > b/drivers/video/fbdev/aty/radeon_pm.c > index b5fbd5329652..97a5972f5b1f 100644 > --- a/drivers/video/fbdev/aty/radeon_pm.c > +++ b/drivers/video/fbdev/aty/radeon_pm.c > @@ -22,7 +22,6 @@ > > #ifdef CONFIG_PPC_PMAC > #include > -#include > #include > #endif > > diff --git a/drivers/video/fbdev/aty/radeonfb.h > b/drivers/video/fbdev/aty/radeonfb.h > index 93f403cbb415..91d81b576231 100644 > --- a/drivers/video/fbdev/aty/radeonfb.h > +++ b/drivers/video/fbdev/aty/radeonfb.h > @@ -21,7 +21,7 @@ > > #include > > -#if defined(CONFIG_PPC) || defined(CONFIG_SPARC) > +#ifdef CONFIG_SPARC > #include > #endif > > diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c > index bd59e7b11ed5..aba46118b208 100644 > --- a/drivers/video/fbdev/controlfb.c > +++ b/drivers/video/fbdev/controlfb.c > @@ -47,9 +47,6 @@ > #include > #include > #include > -#ifdef CONFIG_PPC_PMAC > -#include > -#endif > #ifdef CONFIG_BOOTX_TEXT > #include > #endif > diff --git a/drivers/video/fbdev/matrox/matroxfb_base.h > b/drivers/video/fbdev/matrox/matroxfb_base.h > index 759dee996af1..958be6805f87 100644 > --- a/drivers/video/fbdev/matrox/matroxfb_base.h > +++ b/drivers/video/fbdev/matrox/matroxfb_base.h > @@ -47,7 +47,6 @@ > #include > > #if defined(CONFIG_PPC_PMAC) > -#include > #include "../macmodes.h" > #endif > > diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c > b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c > index 63721337a377..a7508f5be343 100644 > --- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c > +++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c > @@ -18,6 +18,8 @@ > #include > #include > #if defined(CONFIG_OF) > +#include > +#include > #include > #endif > #include "mb862xxfb.h" > diff --git a/drivers/video/fbdev/platinumfb.c > b/drivers/video/fbdev/platinumfb.c > index ce413a9df06e..5b9e26ea6449 100644 > --- a/drivers/video/fbdev/platinumfb.c > +++ b/drivers/video/fbdev/platinumfb.c > @@ -30,9 +30,9 @@ > #include > #include > #include > +#include > #include > #include > -#include > > #include "macmodes.h" > #include "platinumfb.h" > diff --git a/drivers/video/fbdev/valkyriefb.c > b/drivers/video/fbdev/valkyriefb.c > index 8425afe37d7c..a6c9d4f26669 100644 > --- a/drivers/video/fbdev/valkyriefb.c > +++ b/drivers/video/fbdev/valkyriefb.c > @@ -54,10 +54,9 @@ > #include > #include > #include > +#include > #ifdef CONFIG_MAC > #include > -#else > -#include > #endif > > #include "macmodes.h"
Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus
On Sat, 2 Apr 2022 at 20:06, Doug Anderson wrote: > > Hi, > > On Sat, Apr 2, 2022 at 3:37 AM Dmitry Baryshkov > wrote: > > > > On 01/04/2022 02:22, Doug Anderson wrote: > > > Hi, > > > > > > On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti > > > wrote: > > >> > > >> @@ -1547,6 +1593,10 @@ int msm_dp_modeset_init(struct msm_dp > > >> *dp_display, struct drm_device *dev, > > >> > > >> dp_display->encoder = encoder; > > >> > > >> + ret = dp_display_get_next_bridge(dp_display); > > >> + if (ret) > > >> + return ret; > > > > > > It feels weird to me that this is in a function called "modeset_init", > > > though I certainly don't know the structure of the MSM display code > > > well enough to fully comment. > > > > It's called modeset_init() as it initializes KMS objects used by DP > > driver. We have similar functions for dsi and hdmi > > Sorry, I wasn't meaning to imply that modeset_init() was a bad name or > anything. Mostly saying that I wasn't sure that modeset init was the > proper time to populate the aux bus. ...but then again, perhaps it is > given the current structure of this driver? > > > > > My expectation would have been that > > > devm_of_dp_aux_populate_ep_devices() would have been called from your > > > probe routine and then you would have returned -EPROBE_DEFER from your > > > probe if you were unable to find the panel afterwards. > > > > I don't think it's possible to call it from probe() since > > drm_dp_aux_register() is called only from dp_display_bind(). > > The PHY also isn't initialized at that moment, so we can not probe AUX > > devices. > > > > The overall semantics of the AUX bus is not clear to me. > > Typically the bus is populated (and probed) when devices are accessible. > > But for the display related buses this might not be the case. > > In general the AUX bus is modeled much like the i2c bus. You probe the > sub-device when you're able to transfer. Then you can confirm that the > device is actually there and init the device. > > > > For example for the DSI bus we clearly define that DSI transfer are not > > possible before the corresponding bridge's (or panel's) enable call. > > > > Maybe the same approach should be adopted for the AUX bus. This would > > allow us to populate the AUX bus before hardware access is actually > > possible, thus creating all the DRM bridges before the hardware is > > actually up and running. > > So I guess what you're proposing is that you could probe the devices > under the AUX bus and they could acquire resources (and possibly > return EPROBE_DEFER) at a point in time _before_ it's actually > possible to transfer. Then I guess you'd later do the transfer? Exactly. > > I guess conceivably one could re-design the DRM subsystem like that, > but I don't think it's trivial. The problem is that the DRM subsystem is already designed like that. All the bridge chains are static. They are created during the device probe. And the modes are populated later (via the get_modes() callback), after the HPD signal is delivered. For the encoder/bridge chains it is explicitly stated that the display pipe (clocks and timing signals) are not running before bridge's enable() callback or after the disable() callback being called. > Why? I believe that we need to know > things about the panel at probe time. For instance, we need to be able > to populate the panel's modes. As I said, panel modes are not needed at the probe time. The fact that most (if not all) of the panel drivers provide them in the platform data (and thus modes are typically populated at the probe time) comes from the fact that the panel is usually a known static piece of hardware. With the generic edp-panel this is no longer the case. A single device handles a (probed) variety of panels. Compare it with the generic monitor: We have a known bridge (display-connector.c), so the driver can build the display chain. However a set of modes is not known till the actual monitor is plugged into the device. > To get this information we need the > EDID which means we need to be able to do a transfer. If we're using > an AUX backlight we also need to add info about the backlight at probe > time and that also needs the transfer to work. Yes, the backlight is the problem in the suggested design. I'm not sure when panel->backlight has to be populated for things to work. If we can set it after the probe but before calling into mode_set/drm_bridge_chain_enable(), then it should be fine. > So I guess the net result is maybe we should just keep it where it is. > Long term I'd be interested in knowing if there's a reason why we > can't structure the driver so that AUX transfers can happen with less > intertwining with the rest of the code, but that can happen later. I > would expect that you'd basically just need clocks and regulators on > and maybe your PHY on. Ideally with some pm_runtime fun we should be > able to do that independently with anything else the driver n
Re: [RFC][PATCH 1/3] dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory
On 4/1/22 20:36, Rob Herring wrote: On Fri, Apr 1, 2022 at 11:38 AM Marek Vasut wrote: Make the width-mm/height-mm panel properties mandatory to correctly report the panel dimensions to the OS. Adding required properties is an ABI break. Per discussion with Noralf in 2/3, these bindings entered in 5.18 merge window, so maybe there is still chance to fix them before rc1/rc2 ? I.e. they were not shipped in any kernel release yet.
Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()
Den 02.04.2022 19.55, skrev Marek Vasut: > On 4/2/22 19:08, Noralf Trønnes wrote: >> >> >> Den 02.04.2022 18.39, skrev Marek Vasut: >>> On 4/2/22 09:45, Noralf Trønnes wrote: Den 02.04.2022 06.28, skrev Marek Vasut: > On 4/2/22 05:19, Laurent Pinchart wrote: >> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote: >>> On 4/1/22 20:46, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote: > Make the width-mm/height-mm panel properties mandatory in > of_get_drm_panel_display_mode(), print error message and > return -ve in case these DT properties are not present. > This is needed to correctly report panel dimensions. Can we guarantee this won't cause a regression ? >>> >>> For the upstream DTs, I think we can. >>> For downstream DTs, we cannot know. >> >> Are there users of this function whose DT bindings don't require the >> width-mm and height-mm properties ? > > There is literally one user of this function upstream: > drivers/gpu/drm/tiny/panel-mipi-dbi.c Yes, the function was added for that driver since it was so generic in nature. What about adding an argument to of_get_drm_panel_display_mode() that tells if the properties are mandatory or not? >>> >>> Sure, we can do that, but maybe the question here is even bigger than >>> this series. >>> >>> Should every panel set mandatory width_mm/height_mm so e.g. the user >>> space can infer DPI from it and set up scaling accordingly, or should >>> width_mm/height_mm be optional ? >>> >>> I think width_mm/height_mm should be mandatory for all panels. >>> >>> Thoughts ? >> >> If this had come up during the review of the driver I would have no >> problem making it mandatory. It makes sense for DPI. Maybe it's possible >> to get around the ABI break by getting in a change through -fixes before >> 5.18 is released? I'm fine with that. > > Well that's awesome, the dbi-spi.yaml didn't land in any kernel release > yet, so we still have a chance to fix it ? It entered this merge window.
Re: [PATCH AUTOSEL 5.17 001/149] drm: Add orientation quirk for GPD Win Max
Le Sat, Apr 02, 2022 at 11:14:58AM +0200, Hans de Goede a écrit : > Hi, > > On 4/1/22 22:33, Anisse Astier wrote: > > Hi Sasha, > > > > Le Fri, Apr 01, 2022 at 10:23:08AM -0400, Sasha Levin a écrit : > >> From: Anisse Astier > >> > >> [ Upstream commit 0b464ca3e0dd3cec65f28bc6d396d82f19080f69 ] > >> > >> Panel is 800x1280, but mounted on a laptop form factor, sideways. > >> > >> Signed-off-by: Anisse Astier > >> Reviewed-by: Hans de Goede > >> Signed-off-by: Jani Nikula > >> Link: > >> https://patchwork.freedesktop.org/patch/msgid/2021122900.53128-3-ani...@astier.eu > >> Signed-off-by: Sasha Levin > > > > I don't think this patch will be very useful, because it won't fix the > > device's display orientation without the previous patch it came with, > > titled "drm/i915/opregion: add support for mailbox #5 EDID" > > (e35d8762b04f89f9f5a188d0c440d3a2c1d010ed); while I'd like both to be > > added > > Well actually it will already put e.g. the text console the right way up > since efifb also uses this quirks and gives a hint to fbcon to rotate > the text. So it is not entirely useless. > > And since all quirks added to drivers/gpu/drm/drm_panel_orientation_quirks.c > typically get backported having this one in place now will avoid conflicts > with future backports. > > That combined with not really seeing a downside to already having > this in place even without the i915 support being sorted out makes > me lean more towards the direction of believing that having this > in 5.17 is fine... > Good points; lets's keep it in the stable queues. Thanks, Anisse
Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()
On 4/2/22 19:08, Noralf Trønnes wrote: Den 02.04.2022 18.39, skrev Marek Vasut: On 4/2/22 09:45, Noralf Trønnes wrote: Den 02.04.2022 06.28, skrev Marek Vasut: On 4/2/22 05:19, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote: On 4/1/22 20:46, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote: Make the width-mm/height-mm panel properties mandatory in of_get_drm_panel_display_mode(), print error message and return -ve in case these DT properties are not present. This is needed to correctly report panel dimensions. Can we guarantee this won't cause a regression ? For the upstream DTs, I think we can. For downstream DTs, we cannot know. Are there users of this function whose DT bindings don't require the width-mm and height-mm properties ? There is literally one user of this function upstream: drivers/gpu/drm/tiny/panel-mipi-dbi.c Yes, the function was added for that driver since it was so generic in nature. What about adding an argument to of_get_drm_panel_display_mode() that tells if the properties are mandatory or not? Sure, we can do that, but maybe the question here is even bigger than this series. Should every panel set mandatory width_mm/height_mm so e.g. the user space can infer DPI from it and set up scaling accordingly, or should width_mm/height_mm be optional ? I think width_mm/height_mm should be mandatory for all panels. Thoughts ? If this had come up during the review of the driver I would have no problem making it mandatory. It makes sense for DPI. Maybe it's possible to get around the ABI break by getting in a change through -fixes before 5.18 is released? I'm fine with that. Well that's awesome, the dbi-spi.yaml didn't land in any kernel release yet, so we still have a chance to fix it ? Rob ?
Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()
Den 02.04.2022 18.39, skrev Marek Vasut: > On 4/2/22 09:45, Noralf Trønnes wrote: >> >> >> Den 02.04.2022 06.28, skrev Marek Vasut: >>> On 4/2/22 05:19, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote: > On 4/1/22 20:46, Laurent Pinchart wrote: >> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote: >>> Make the width-mm/height-mm panel properties mandatory in >>> of_get_drm_panel_display_mode(), print error message and >>> return -ve in case these DT properties are not present. >>> This is needed to correctly report panel dimensions. >> >> Can we guarantee this won't cause a regression ? > > For the upstream DTs, I think we can. > For downstream DTs, we cannot know. Are there users of this function whose DT bindings don't require the width-mm and height-mm properties ? >>> >>> There is literally one user of this function upstream: >>> drivers/gpu/drm/tiny/panel-mipi-dbi.c >> >> Yes, the function was added for that driver since it was so generic in >> nature. What about adding an argument to of_get_drm_panel_display_mode() >> that tells if the properties are mandatory or not? > > Sure, we can do that, but maybe the question here is even bigger than > this series. > > Should every panel set mandatory width_mm/height_mm so e.g. the user > space can infer DPI from it and set up scaling accordingly, or should > width_mm/height_mm be optional ? > > I think width_mm/height_mm should be mandatory for all panels. > > Thoughts ? If this had come up during the review of the driver I would have no problem making it mandatory. It makes sense for DPI. Maybe it's possible to get around the ABI break by getting in a change through -fixes before 5.18 is released? I'm fine with that. Noralf.
Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus
Hi, On Sat, Apr 2, 2022 at 3:37 AM Dmitry Baryshkov wrote: > > On 01/04/2022 02:22, Doug Anderson wrote: > > Hi, > > > > On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti > > wrote: > >> > >> @@ -1547,6 +1593,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, > >> struct drm_device *dev, > >> > >> dp_display->encoder = encoder; > >> > >> + ret = dp_display_get_next_bridge(dp_display); > >> + if (ret) > >> + return ret; > > > > It feels weird to me that this is in a function called "modeset_init", > > though I certainly don't know the structure of the MSM display code > > well enough to fully comment. > > It's called modeset_init() as it initializes KMS objects used by DP > driver. We have similar functions for dsi and hdmi Sorry, I wasn't meaning to imply that modeset_init() was a bad name or anything. Mostly saying that I wasn't sure that modeset init was the proper time to populate the aux bus. ...but then again, perhaps it is given the current structure of this driver? > > My expectation would have been that > > devm_of_dp_aux_populate_ep_devices() would have been called from your > > probe routine and then you would have returned -EPROBE_DEFER from your > > probe if you were unable to find the panel afterwards. > > I don't think it's possible to call it from probe() since > drm_dp_aux_register() is called only from dp_display_bind(). > The PHY also isn't initialized at that moment, so we can not probe AUX > devices. > > The overall semantics of the AUX bus is not clear to me. > Typically the bus is populated (and probed) when devices are accessible. > But for the display related buses this might not be the case. In general the AUX bus is modeled much like the i2c bus. You probe the sub-device when you're able to transfer. Then you can confirm that the device is actually there and init the device. > For example for the DSI bus we clearly define that DSI transfer are not > possible before the corresponding bridge's (or panel's) enable call. > > Maybe the same approach should be adopted for the AUX bus. This would > allow us to populate the AUX bus before hardware access is actually > possible, thus creating all the DRM bridges before the hardware is > actually up and running. So I guess what you're proposing is that you could probe the devices under the AUX bus and they could acquire resources (and possibly return EPROBE_DEFER) at a point in time _before_ it's actually possible to transfer. Then I guess you'd later do the transfer? I guess conceivably one could re-design the DRM subsystem like that, but I don't think it's trivial. Why? I believe that we need to know things about the panel at probe time. For instance, we need to be able to populate the panel's modes. To get this information we need the EDID which means we need to be able to do a transfer. If we're using an AUX backlight we also need to add info about the backlight at probe time and that also needs the transfer to work. So I guess the net result is maybe we should just keep it where it is. Long term I'd be interested in knowing if there's a reason why we can't structure the driver so that AUX transfers can happen with less intertwining with the rest of the code, but that can happen later. I would expect that you'd basically just need clocks and regulators on and maybe your PHY on. Ideally with some pm_runtime fun we should be able to do that independently with anything else the driver needs to do? -Doug
Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()
On 4/2/22 09:45, Noralf Trønnes wrote: Den 02.04.2022 06.28, skrev Marek Vasut: On 4/2/22 05:19, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote: On 4/1/22 20:46, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote: Make the width-mm/height-mm panel properties mandatory in of_get_drm_panel_display_mode(), print error message and return -ve in case these DT properties are not present. This is needed to correctly report panel dimensions. Can we guarantee this won't cause a regression ? For the upstream DTs, I think we can. For downstream DTs, we cannot know. Are there users of this function whose DT bindings don't require the width-mm and height-mm properties ? There is literally one user of this function upstream: drivers/gpu/drm/tiny/panel-mipi-dbi.c Yes, the function was added for that driver since it was so generic in nature. What about adding an argument to of_get_drm_panel_display_mode() that tells if the properties are mandatory or not? Sure, we can do that, but maybe the question here is even bigger than this series. Should every panel set mandatory width_mm/height_mm so e.g. the user space can infer DPI from it and set up scaling accordingly, or should width_mm/height_mm be optional ? I think width_mm/height_mm should be mandatory for all panels. Thoughts ?
Re: [PATCH 4/4] drm/etnaviv: Don't break exclusive fence ordering
Hi, There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore them. A better fix would be to us a dma_fence_chain or _array like e.g. amdgpu now uses, but it probably makes sense to lift this into dma-resv.c code as a proper concept, so that drivers don't have to hack up their own solution each on their own. Hence go with the simple fix for now. I find a typo in the commit message, us -> use
[PATCH] drm/radeon: change si_default_state table from global to static
Smatch reports these issues
si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
was not declared. Should it be static?
si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
was not declared. Should it be static?
Both symbols are only used in si.c. Single file symbols
should be static. So move the si_default_state and
si_default_size to si.c and change their
storage-class-specifier to static.
Remove unneeded si_blit_shaders.[c|h]
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/si.c | 224 +++-
drivers/gpu/drm/radeon/si_blit_shaders.c | 253 ---
drivers/gpu/drm/radeon/si_blit_shaders.h | 32 ---
4 files changed, 224 insertions(+), 287 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.h
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 11c97edde54d..664381f4eb07 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
- si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
+ radeon_prime.o cik.o cik_blit_shaders.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 8d5e4b25609d..a4032702e302 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -38,7 +38,6 @@
#include "radeon_asic.h"
#include "radeon_audio.h"
#include "radeon_ucode.h"
-#include "si_blit_shaders.h"
#include "si.h"
#include "sid.h"
@@ -3553,6 +3552,229 @@ static int si_cp_load_microcode(struct radeon_device
*rdev)
return 0;
}
+static const u32 si_default_state[] = {
+ 0xc0066900,
+ 0x,
+ 0x0060, /* DB_RENDER_CONTROL */
+ 0x, /* DB_COUNT_CONTROL */
+ 0x, /* DB_DEPTH_VIEW */
+ 0x002a, /* DB_RENDER_OVERRIDE */
+ 0x, /* DB_RENDER_OVERRIDE2 */
+ 0x, /* DB_HTILE_DATA_BASE */
+
+ 0xc0046900,
+ 0x0008,
+ 0x, /* DB_DEPTH_BOUNDS_MIN */
+ 0x, /* DB_DEPTH_BOUNDS_MAX */
+ 0x, /* DB_STENCIL_CLEAR */
+ 0x, /* DB_DEPTH_CLEAR */
+
+ 0xc0036900,
+ 0x000f,
+ 0x, /* DB_DEPTH_INFO */
+ 0x, /* DB_Z_INFO */
+ 0x, /* DB_STENCIL_INFO */
+
+ 0xc0016900,
+ 0x0080,
+ 0x, /* PA_SC_WINDOW_OFFSET */
+
+ 0xc00d6900,
+ 0x0083,
+ 0x, /* PA_SC_CLIPRECT_RULE */
+ 0x, /* PA_SC_CLIPRECT_0_TL */
+ 0x20002000, /* PA_SC_CLIPRECT_0_BR */
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x, /* PA_SC_EDGERULE */
+ 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+ 0x000f, /* CB_TARGET_MASK */
+ 0x000f, /* CB_SHADER_MASK */
+
+ 0xc0226900,
+ 0x0094,
+ 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+ 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x, /* PA_SC_VPORT_ZMIN_0 */
+ 0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+ 0xc0026900,
+ 0x00d9,
+ 0x, /* CP_RINGID */
+ 0x, /* CP_VMID */
+
+ 0xc0046900,
+ 0x0100,
+ 0x, /* VGT_MAX_VTX_INDX */
+ 0x, /* VGT_MIN_VTX_INDX */
+ 0x, /* VGT_INDX_OFFSET */
+ 0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+
+ 0xc0046900,
+ 0x0105,
+ 0x, /* CB_BLEND_RED */
+ 0x, /* CB_BLEND_GREEN */
+ 0x, /* CB_BLEND_BLUE */
+ 0x, /* CB_BLEND_ALPHA */
+
+ 0xc0016900,
+ 0x01e0,
+ 0x, /* CB_BLEND0_CONTROL */
+
+ 0xc00e6900,
+ 0x0200,
+
[PATCH] drm/etnaviv: introduce a function to create etnaviv platform device
This patch make the code more clear, call of_node_put(np) only once
in for_each_compatible_node(np, NULL, "vivante,gc") loop instead of
three.
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 36 +--
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 0b756ecb1bc2..42cb624cf1ae 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -659,6 +659,26 @@ static struct platform_driver etnaviv_platform_driver = {
static struct platform_device *etnaviv_drm;
+static int etnaviv_create_platform_device(const char *name)
+{
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
+ if (!pdev)
+ return -ENOMEM;
+
+ ret = platform_device_add(pdev);
+ if (ret) {
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ etnaviv_drm = pdev;
+
+ return 0;
+}
+
static int __init etnaviv_init(void)
{
struct platform_device *pdev;
@@ -683,22 +703,12 @@ static int __init etnaviv_init(void)
if (!of_device_is_available(np))
continue;
- pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE);
- if (!pdev) {
- ret = -ENOMEM;
- of_node_put(np);
- goto unregister_platform_driver;
- }
+ of_node_put(np);
- ret = platform_device_add(pdev);
- if (ret) {
- platform_device_put(pdev);
- of_node_put(np);
+ ret = etnaviv_create_platform_device("etnaviv");
+ if (ret)
goto unregister_platform_driver;
- }
- etnaviv_drm = pdev;
- of_node_put(np);
break;
}
--
2.25.1
Patch "drm/dp: Fix off-by-one in register cache size" has been added to the 5.17-stable tree
This is a note to let you know that I've just added the patch titled
drm/dp: Fix off-by-one in register cache size
to the 5.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-dp-fix-off-by-one-in-register-cache-size.patch
and it can be found in the queue-5.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d4da1f27396fb1dde079447a3612f4f512caed07 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 24 Feb 2022 19:56:09 -0800
Subject: drm/dp: Fix off-by-one in register cache size
From: Kees Cook
commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.
The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'}
[-Werror=array-bounds]
3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
| ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
3126 | int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
|
~^~~
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding
Link:
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman
---
include/drm/drm_dp_helper.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -456,7 +456,7 @@ struct drm_panel;
#define DP_FEC_CAPABILITY_10x091 /* 2.0 */
/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
#define DP_PCON_DSC_ENCODER 0x092
# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
Patches currently in stable-queue which might be from keesc...@chromium.org are
queue-5.17/stack-constrain-and-fix-stack-offset-randomization-w.patch
queue-5.17/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
queue-5.17/selftests-lkdtm-add-ubsan-config.patch
queue-5.17/fs-binfmt_elf-fix-at_phdr-for-unusual-elf-files.patch
queue-5.17/media-omap3isp-use-struct_group-for-memcpy-region.patch
queue-5.17/gcc-plugins-stackleak-exactly-match-strings-instead-.patch
queue-5.17/exec-force-single-empty-string-when-argv-is-empty.patch
queue-5.17/drm-dp-fix-off-by-one-in-register-cache-size.patch
queue-5.17/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch
queue-5.17/drm-dp-fix-oob-read-when-handling-post-cursor2-regis.patch
Patch "drm/dp: Fix off-by-one in register cache size" has been added to the 5.16-stable tree
This is a note to let you know that I've just added the patch titled
drm/dp: Fix off-by-one in register cache size
to the 5.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-dp-fix-off-by-one-in-register-cache-size.patch
and it can be found in the queue-5.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d4da1f27396fb1dde079447a3612f4f512caed07 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 24 Feb 2022 19:56:09 -0800
Subject: drm/dp: Fix off-by-one in register cache size
From: Kees Cook
commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.
The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'}
[-Werror=array-bounds]
3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
| ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
3126 | int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
|
~^~~
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding
Link:
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman
---
include/drm/drm_dp_helper.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -456,7 +456,7 @@ struct drm_panel;
#define DP_FEC_CAPABILITY_10x091 /* 2.0 */
/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
#define DP_PCON_DSC_ENCODER 0x092
# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
Patches currently in stable-queue which might be from keesc...@chromium.org are
queue-5.16/stack-constrain-and-fix-stack-offset-randomization-w.patch
queue-5.16/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
queue-5.16/selftests-lkdtm-add-ubsan-config.patch
queue-5.16/fs-binfmt_elf-fix-at_phdr-for-unusual-elf-files.patch
queue-5.16/media-omap3isp-use-struct_group-for-memcpy-region.patch
queue-5.16/gcc-plugins-stackleak-exactly-match-strings-instead-.patch
queue-5.16/exec-force-single-empty-string-when-argv-is-empty.patch
queue-5.16/drm-dp-fix-off-by-one-in-register-cache-size.patch
queue-5.16/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch
Patch "drm/dp: Fix off-by-one in register cache size" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/dp: Fix off-by-one in register cache size
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-dp-fix-off-by-one-in-register-cache-size.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d4da1f27396fb1dde079447a3612f4f512caed07 Mon Sep 17 00:00:00 2001
From: Kees Cook
Date: Thu, 24 Feb 2022 19:56:09 -0800
Subject: drm/dp: Fix off-by-one in register cache size
From: Kees Cook
commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.
The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'}
[-Werror=array-bounds]
3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
| ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
3126 | int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
|
~^~~
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding
Link:
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman
---
include/drm/drm_dp_helper.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -455,7 +455,7 @@ struct drm_panel;
# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
#define DP_PCON_DSC_ENCODER 0x092
# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
Patches currently in stable-queue which might be from keesc...@chromium.org are
queue-5.15/stack-constrain-and-fix-stack-offset-randomization-w.patch
queue-5.15/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
queue-5.15/selftests-lkdtm-add-ubsan-config.patch
queue-5.15/fs-binfmt_elf-fix-at_phdr-for-unusual-elf-files.patch
queue-5.15/gcc-plugins-stackleak-exactly-match-strings-instead-.patch
queue-5.15/exec-force-single-empty-string-when-argv-is-empty.patch
queue-5.15/drm-dp-fix-off-by-one-in-register-cache-size.patch
queue-5.15/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch
[PATCH] drivers/dma-buf: dma-buf.c: fix a typo
Signed-off-by: Sui Jingfeng <15330273...@189.cn> --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index df23239b04fc..775d3afb4169 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -443,7 +443,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) *as a file descriptor by calling dma_buf_fd(). * * 2. Userspace passes this file-descriptors to all drivers it wants this buffer - *to share with: First the filedescriptor is converted to a &dma_buf using + *to share with: First the file descriptor is converted to a &dma_buf using *dma_buf_get(). Then the buffer is attached to the device using *dma_buf_attach(). * -- 2.25.1
Patch "drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB" has been added to the 5.16-stable tree
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
to the 5.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
and it can be found in the queue-5.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 1 Feb 2022 12:53:05 +0100
Subject: drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
From: Thomas Zimmermann
commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.
Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)
For shadow buffers, also set the FBINFO_READS_FAST hint.
v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag
Signed-off-by: Thomas Zimmermann
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe
function")
Reviewed-by: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = fb->height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+ fbi->flags = FBINFO_DEFAULT;
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+ fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
- if (map.is_iomem)
+ if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
- else
+ } else {
fbi->screen_buffer = map.vaddr;
+ fbi->flags |= FBINFO_VIRTFB;
+ }
/*
* Shamelessly leak the physical address to user-space. As
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.16/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch
queue-5.16/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
queue-5.16/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch
queue-5.16/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch
Patch "drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 1 Feb 2022 12:53:05 +0100
Subject: drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
From: Thomas Zimmermann
commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.
Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)
For shadow buffers, also set the FBINFO_READS_FAST hint.
v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag
Signed-off-by: Thomas Zimmermann
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe
function")
Reviewed-by: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = fb->height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+ fbi->flags = FBINFO_DEFAULT;
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+ fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
- if (map.is_iomem)
+ if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
- else
+ } else {
fbi->screen_buffer = map.vaddr;
+ fbi->flags |= FBINFO_VIRTFB;
+ }
/*
* Shamelessly leak the physical address to user-space. As
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.15/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch
queue-5.15/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
queue-5.15/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch
queue-5.15/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch
Patch "drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB" has been added to the 5.17-stable tree
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
to the 5.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
and it can be found in the queue-5.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 1 Feb 2022 12:53:05 +0100
Subject: drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB
From: Thomas Zimmermann
commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.
Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)
For shadow buffers, also set the FBINFO_READS_FAST hint.
v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag
Signed-off-by: Thomas Zimmermann
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe
function")
Reviewed-by: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = sizes->surface_height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+ fbi->flags = FBINFO_DEFAULT;
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+ fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
- if (map.is_iomem)
+ if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
- else
+ } else {
fbi->screen_buffer = map.vaddr;
+ fbi->flags |= FBINFO_VIRTFB;
+ }
/*
* Shamelessly leak the physical address to user-space. As
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.17/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch
queue-5.17/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch
queue-5.17/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch
queue-5.17/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch
Re: [PATCH v8 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g
Hi Zhi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm/drm-next next-20220401]
[cannot apply to tegra-drm/drm/tegra/for-next airlied/drm-next v5.17]
[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/intel-lab-lkp/linux/commits/Zhi-Wang/Refactor-GVT-g-MMIO-tracking-table-and-handlers/20220401-210319
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig
(https://download.01.org/0day-ci/archive/20220402/202204022008.nct9wukc-...@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-19) 11.2.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/eeae6480610a35a271461e864f84540d6849d8d6
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Zhi-Wang/Refactor-GVT-g-MMIO-tracking-table-and-handlers/20220401-210319
git checkout eeae6480610a35a271461e864f84540d6849d8d6
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/
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/i915/gvt/gvt.h:39,
from :
>> drivers/gpu/drm/i915/intel_gvt.h:66:15: error: no previous prototype for
>> 'intel_gvt_get_device_type' [-Werror=missing-prototypes]
66 | unsigned long intel_gvt_get_device_type(struct drm_i915_private
*i915)
| ^
drivers/gpu/drm/i915/intel_gvt.h:71:41: error: 'struct
intel_gvt_mmio_table_iter' declared inside parameter list will not be visible
outside of this definition or declaration [-Werror]
71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter
*iter)
| ^
>> drivers/gpu/drm/i915/intel_gvt.h:71:5: error: no previous prototype for
>> 'intel_gvt_iterate_mmio_table' [-Werror=missing-prototypes]
71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter
*iter)
| ^~~~
In file included from drivers/gpu/drm/i915/gvt/gvt.h:43,
from :
drivers/gpu/drm/i915/gvt/mmio.h:74:15: error: conflicting types for
'intel_gvt_get_device_type'; have 'long unsigned int(struct intel_gvt *)'
74 | unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt);
| ^
In file included from drivers/gpu/drm/i915/gvt/gvt.h:39,
from :
drivers/gpu/drm/i915/intel_gvt.h:66:15: note: previous definition of
'intel_gvt_get_device_type' with type 'long unsigned int(struct
drm_i915_private *)'
66 | unsigned long intel_gvt_get_device_type(struct drm_i915_private
*i915)
| ^
cc1: all warnings being treated as errors
--
In file included from :
>> drivers/gpu/drm/i915/intel_gvt.h:66:15: error: no previous prototype for
>> 'intel_gvt_get_device_type' [-Werror=missing-prototypes]
66 | unsigned long intel_gvt_get_device_type(struct drm_i915_private
*i915)
| ^
drivers/gpu/drm/i915/intel_gvt.h:71:41: error: 'struct
intel_gvt_mmio_table_iter' declared inside parameter list will not be visible
outside of this definition or declaration [-Werror]
71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter
*iter)
| ^
>> drivers/gpu/drm/i915/intel_gvt.h:71:5: error: no previous prototype for
>> 'intel_gvt_iterate_mmio_table' [-Werror=missing-prototypes]
71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter
*iter)
| ^~~~
cc1: all warnings being treated as errors
vim +/intel_gvt_get_device_type +66 drivers/gpu/drm/i915/intel_gvt.h
65
> 66 unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915)
67 {
68 return 0;
69 }
70
> 71 int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter)
72 {
73 return 0;
74 }
75 #endif
76
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH 0/1] drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels
On Sat, Apr 02, 2022 at 11:30:28AM +0200, Hans de Goede wrote: > Hi Greg, > > Fedora 36 has switched from efifb to simpledrm as the pre-native-GPU driver > fb provider and the lack of this patch is causing issues for devices with > non up-right mounted LCD panels (1), can you please add this to the 5.17 > stable > series? > > Regards, > > Hans > > 1) https://bugzilla.redhat.com/show_bug.cgi?id=2071134 > > > Hans de Goede (1): > drm/simpledrm: Add "panel orientation" property on non-upright mounted > LCD panels > > drivers/gpu/drm/tiny/simpledrm.c | 3 +++ > 1 file changed, 3 insertions(+) > > -- > 2.35.1 > Now queued up, thanks. greg k-h
Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus
On 01/04/2022 02:22, Doug Anderson wrote:
Hi,
On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti
wrote:
@@ -1547,6 +1593,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
struct drm_device *dev,
dp_display->encoder = encoder;
+ ret = dp_display_get_next_bridge(dp_display);
+ if (ret)
+ return ret;
It feels weird to me that this is in a function called "modeset_init",
though I certainly don't know the structure of the MSM display code
well enough to fully comment.
It's called modeset_init() as it initializes KMS objects used by DP
driver. We have similar functions for dsi and hdmi
My expectation would have been that
devm_of_dp_aux_populate_ep_devices() would have been called from your
probe routine and then you would have returned -EPROBE_DEFER from your
probe if you were unable to find the panel afterwards.
I don't think it's possible to call it from probe() since
drm_dp_aux_register() is called only from dp_display_bind().
The PHY also isn't initialized at that moment, so we can not probe AUX
devices.
The overall semantics of the AUX bus is not clear to me.
Typically the bus is populated (and probed) when devices are accessible.
But for the display related buses this might not be the case.
For example for the DSI bus we clearly define that DSI transfer are not
possible before the corresponding bridge's (or panel's) enable call.
Maybe the same approach should be adopted for the AUX bus. This would
allow us to populate the AUX bus before hardware access is actually
possible, thus creating all the DRM bridges before the hardware is
actually up and running.
Huh, but I guess you _are_ getting called (indirectly) from
dpu_kms_hw_init() and I can't imagine AUX transfers working before
that function is called, so maybe I should just accept that it's
complicated and let those who understand this driver better confirm
that it's OK. ;-)
@@ -140,5 +140,6 @@ struct dp_parser {
* can be parsed using this module.
*/
struct dp_parser *dp_parser_get(struct platform_device *pdev);
+int dp_parser_find_next_bridge(struct dp_parser *parser);
Everything else in this file is described w/ kerneldoc. Shouldn't your
function also have a kerneldoc comment?
--
With best wishes
Dmitry
[PATCH] video: fbdev: Prepare cleanup of powerpc's asm/prom.h
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by: Christophe Leroy --- drivers/video/fbdev/aty/aty128fb.c | 1 - drivers/video/fbdev/aty/atyfb_base.c | 1 - drivers/video/fbdev/aty/radeon_pm.c| 1 - drivers/video/fbdev/aty/radeonfb.h | 2 +- drivers/video/fbdev/controlfb.c| 3 --- drivers/video/fbdev/matrox/matroxfb_base.h | 1 - drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 2 ++ drivers/video/fbdev/platinumfb.c | 2 +- drivers/video/fbdev/valkyriefb.c | 3 +-- 9 files changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/video/fbdev/aty/aty128fb.c b/drivers/video/fbdev/aty/aty128fb.c index 6ff16d3132e5..b26c81233b6b 100644 --- a/drivers/video/fbdev/aty/aty128fb.c +++ b/drivers/video/fbdev/aty/aty128fb.c @@ -68,7 +68,6 @@ #ifdef CONFIG_PPC_PMAC #include #include -#include #include "../macmodes.h" #endif diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 1aef3d6ebd88..a3e6faed7745 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -79,7 +79,6 @@ #ifdef __powerpc__ #include -#include #include "../macmodes.h" #endif #ifdef __sparc__ diff --git a/drivers/video/fbdev/aty/radeon_pm.c b/drivers/video/fbdev/aty/radeon_pm.c index b5fbd5329652..97a5972f5b1f 100644 --- a/drivers/video/fbdev/aty/radeon_pm.c +++ b/drivers/video/fbdev/aty/radeon_pm.c @@ -22,7 +22,6 @@ #ifdef CONFIG_PPC_PMAC #include -#include #include #endif diff --git a/drivers/video/fbdev/aty/radeonfb.h b/drivers/video/fbdev/aty/radeonfb.h index 93f403cbb415..91d81b576231 100644 --- a/drivers/video/fbdev/aty/radeonfb.h +++ b/drivers/video/fbdev/aty/radeonfb.h @@ -21,7 +21,7 @@ #include -#if defined(CONFIG_PPC) || defined(CONFIG_SPARC) +#ifdef CONFIG_SPARC #include #endif diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c index bd59e7b11ed5..aba46118b208 100644 --- a/drivers/video/fbdev/controlfb.c +++ b/drivers/video/fbdev/controlfb.c @@ -47,9 +47,6 @@ #include #include #include -#ifdef CONFIG_PPC_PMAC -#include -#endif #ifdef CONFIG_BOOTX_TEXT #include #endif diff --git a/drivers/video/fbdev/matrox/matroxfb_base.h b/drivers/video/fbdev/matrox/matroxfb_base.h index 759dee996af1..958be6805f87 100644 --- a/drivers/video/fbdev/matrox/matroxfb_base.h +++ b/drivers/video/fbdev/matrox/matroxfb_base.h @@ -47,7 +47,6 @@ #include #if defined(CONFIG_PPC_PMAC) -#include #include "../macmodes.h" #endif diff --git a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c index 63721337a377..a7508f5be343 100644 --- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c +++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c @@ -18,6 +18,8 @@ #include #include #if defined(CONFIG_OF) +#include +#include #include #endif #include "mb862xxfb.h" diff --git a/drivers/video/fbdev/platinumfb.c b/drivers/video/fbdev/platinumfb.c index ce413a9df06e..5b9e26ea6449 100644 --- a/drivers/video/fbdev/platinumfb.c +++ b/drivers/video/fbdev/platinumfb.c @@ -30,9 +30,9 @@ #include #include #include +#include #include #include -#include #include "macmodes.h" #include "platinumfb.h" diff --git a/drivers/video/fbdev/valkyriefb.c b/drivers/video/fbdev/valkyriefb.c index 8425afe37d7c..a6c9d4f26669 100644 --- a/drivers/video/fbdev/valkyriefb.c +++ b/drivers/video/fbdev/valkyriefb.c @@ -54,10 +54,9 @@ #include #include #include +#include #ifdef CONFIG_MAC #include -#else -#include #endif #include "macmodes.h" -- 2.35.1
[PATCH] drm/radeon/combios: Prepare cleanup of powerpc's asm/prom.h
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by: Christophe Leroy --- drivers/gpu/drm/radeon/radeon_combios.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 783a6b8802d5..76b7113f0f32 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -38,7 +38,6 @@ /* not sure which of these are needed */ #include #include -#include #endif /* CONFIG_PPC_PMAC */ /* old legacy ATI BIOS routines */ -- 2.35.1
[PATCH 1/1] drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels
commit 94fa115f7b28a3f02611499175e134f0a823b686 upstream. Some devices use e.g. a portrait panel in a standard laptop casing made for landscape panels. efifb calls drm_get_panel_orientation_quirk() and sets fb_info.fbcon_rotate_hint to make fbcon rotate the console so that it shows up-right instead of on its side. When switching to simpledrm the fbcon renders on its side. Call the drm_connector_set_panel_orientation_with_quirk() helper to add a "panel orientation" property on devices listed in the quirk table, to make the fbcon (and aware userspace apps) rotate the image to display properly. Cc: Javier Martinez Canillas Signed-off-by: Hans de Goede Reviewed-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220221220045.11958-1-hdego...@redhat.com --- drivers/gpu/drm/tiny/simpledrm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index d191e87a37b5..f5b8e864a5cd 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -810,6 +810,9 @@ static int simpledrm_device_init_modeset(struct simpledrm_device *sdev) if (ret) return ret; drm_connector_helper_add(connector, &simpledrm_connector_helper_funcs); + drm_connector_set_panel_orientation_with_quirk(connector, + DRM_MODE_PANEL_ORIENTATION_UNKNOWN, + mode->hdisplay, mode->vdisplay); formats = simpledrm_device_formats(sdev, &nformats); -- 2.35.1
[PATCH 0/1] drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels
Hi Greg, Fedora 36 has switched from efifb to simpledrm as the pre-native-GPU driver fb provider and the lack of this patch is causing issues for devices with non up-right mounted LCD panels (1), can you please add this to the 5.17 stable series? Regards, Hans 1) https://bugzilla.redhat.com/show_bug.cgi?id=2071134 Hans de Goede (1): drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels drivers/gpu/drm/tiny/simpledrm.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.35.1
[PATCH] Hvideo: fbdev: pm2fb: Fix a kernel-doc formatting issue
This function had kernel-doc that not used a hash to separate
the function name from the one line description.
The warning was found by running scripts/kernel-doc, which is
caused by using 'make W=1'.
drivers/video/fbdev/pm2fb.c:1507: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Device initialisation
drivers/video/fbdev/pm2fb.c:1714: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Device removal.
Signed-off-by: Haowen Bai
---
drivers/video/fbdev/pm2fb.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index c68725eebee3..d3be2c64f1c0 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -1504,9 +1504,7 @@ static const struct fb_ops pm2fb_ops = {
/**
- * Device initialisation
- *
- * Initialise and allocate resource for PCI device.
+ * pm2fb_probe - Initialise and allocate resource for PCI device.
*
* @pdev: PCI device.
* @id:PCI device ID.
@@ -1711,9 +1709,7 @@ static int pm2fb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
}
/**
- * Device removal.
- *
- * Release all device resources.
+ * pm2fb_remove - Release all device resources.
*
* @pdev: PCI device to clean up.
*/
--
2.7.4
Re: [PATCH] drm/amdgpu/vcn: remove Unneeded semicolon
dear Alex Deucher
I just mean where unneeded semicolon comes from when I add fixes info. As your
remind, I have got it, thank you.
原始邮件
发件人：Alex Deucher
时间：2022年4月1日 21:26
收件人：Paul Menzel
抄送：白浩文 ,David Airlie ,"Pan, Xinhui"
,LKML ,Maling list - DRI
developers ,amd-gfx list
,Daniel Vetter ,Alex Deucher
,Christian König
主题：Re: [PATCH] drm/amdgpu/vcn: remove Unneeded semicolon
On Fri, Apr 1, 2022 at 1:54 AM Paul Menzel wrote:
>
> Dear Haowen,
>
>
> Thank you for your patch.
>
> Am 31.03.22 um 07:56 schrieb Haowen Bai:
>
> In the commit message summary, please use:
>
> Remove unneeded semicolon
>
> > report by coccicheck:
> > drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1951:2-3: Unneeded semicolon
> >
> > fixed c543dcb ("drm/amdgpu/vcn: Add VCN ras error query support")
>
> Please use
>
> Fixes: …
>
> and a commit hash length of 12 characters. (`scripts/checkpatch.pl …`
> should tell you about this.)
I don't know that you need to add a fixes tag unless the patch is an
actual bug fix. Coding style or spelling fixes are not really
critical for getting into stable trees.
Alex
>
>
> Kind regards,
>
> Paul
>
>
> > Signed-off-by: Haowen Bai
> > ---
> > drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> > b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> > index 3e1de8c..17d44be 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
> > @@ -1948,7 +1948,7 @@ static uint32_t
> > vcn_v2_6_query_poison_by_instance(struct amdgpu_device *adev,
> > break;
> > default:
> > break;
> > - };
> > + }
> >
> > if (poison_stat)
> > dev_info(adev->dev, "Poison detected in VCN%d, sub_block%d\n",
Re: [PATCH AUTOSEL 5.17 001/149] drm: Add orientation quirk for GPD Win Max
Hi, On 4/1/22 22:33, Anisse Astier wrote: > Hi Sasha, > > Le Fri, Apr 01, 2022 at 10:23:08AM -0400, Sasha Levin a écrit : >> From: Anisse Astier >> >> [ Upstream commit 0b464ca3e0dd3cec65f28bc6d396d82f19080f69 ] >> >> Panel is 800x1280, but mounted on a laptop form factor, sideways. >> >> Signed-off-by: Anisse Astier >> Reviewed-by: Hans de Goede >> Signed-off-by: Jani Nikula >> Link: >> https://patchwork.freedesktop.org/patch/msgid/2021122900.53128-3-ani...@astier.eu >> Signed-off-by: Sasha Levin > > I don't think this patch will be very useful, because it won't fix the > device's display orientation without the previous patch it came with, > titled "drm/i915/opregion: add support for mailbox #5 EDID" > (e35d8762b04f89f9f5a188d0c440d3a2c1d010ed); while I'd like both to be > added Well actually it will already put e.g. the text console the right way up since efifb also uses this quirks and gives a hint to fbcon to rotate the text. So it is not entirely useless. And since all quirks added to drivers/gpu/drm/drm_panel_orientation_quirks.c typically get backported having this one in place now will avoid conflicts with future backports. That combined with not really seeing a downside to already having this in place even without the i915 support being sorted out makes me lean more towards the direction of believing that having this in 5.17 is fine... Regards, Hans
[PATCH v15 6/6] MAINTAINERS: add maintainers for DRM LOONGSON driver
This patch add myself as maintainer Signed-off-by: Sui Jingfeng <15330273...@189.cn> --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 10476280acb8..21184d8577f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6487,6 +6487,15 @@ T: git git://anongit.freedesktop.org/drm/drm-misc F: drivers/gpu/drm/lima/ F: include/uapi/drm/lima_drm.h +DRM DRIVERS FOR LOONGSON +M: suijingfeng +L: dri-devel@lists.freedesktop.org +S: Maintained +W: https://www.loongson.cn/ +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/loongson/ +F: drivers/gpu/drm/loongson/ + DRM DRIVERS FOR MEDIATEK M: Chun-Kuang Hu M: Philipp Zabel -- 2.25.1
[PATCH v15 5/6] drm/loongson: add drm driver for loongson display controller
There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge chip, the display controller is a PCI device. It have two display pipes but with only one hardware cursor. Each way has a DVO interface which provide RGB888 signals, vertical & horizontal synchronisations, data enable and the pixel clock. Each CRTC is able to drive a 1920x1080@60Hz monitor, the maxmium resolution is 2048x2048. Loongson display controllers are simple which require scanout buffers to be physically contiguous. For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM which is typically 64MB or more. In this case, VRAM helper based driver is intended to be used even through the DC can scanout form system memory. While LS2K1000 is a SoC which is a typically UMA device, only system memory is available. Therefore CMA helper based driver is intended to be used. It is possible to use VRAM helper based driver on LS2K1000 by carving out part of system memory as VRAM though. For LS7A1000, there are 4 dedicated GPIOs whose control registers is located at the DC register space, They are used to emulate two way i2c. One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such GPIO hardwared, they grab i2c adapter from other module, either general purpose GPIO emulated i2c or hardware i2c adapter. +--++---+ | DDR4 || +---+| +--+| | PCIe Root complex | LS7A1000 | || MC0 | +--++-+++| +--+ HT 3.0 | || || | | LS3A4000 |<>| +---++---+ +--++--++-+ +--+ | CPU|<>| | GC1000 | | LSDC |<-->| DDR3 MC |<->| VRAM | +--+ | ++ +-+--+-++-+ +--+ || MC1 +---|--|+ +--+| | | DDR4 | +---+ DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<+ +>|TFP410|--> DVI/HDMI +---+ +--+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, other candicates can be ch7034b, sil9022, ite66121 and lt8618 etc. By design, the code was written in a NOT fully DT dependent way. v2: Fixup warnings reported by kernel test robot v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give more details about lsdc. v4: 1) Add dts required and explain why device tree is required. 2) Give more description about lsdc and VRAM helper based driver. 3) Fix warnings reported by kernel test robot. 4) Introduce stride_alignment member into struct lsdc_chip_desc, the stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500. v5: 1) Using writel and readl replace writeq and readq, to fix kernel test robot report build error on other archtecture. 2) Set default fb format to XRGB at crtc reset time. v6: 1) Explain why we are not switch to drm dridge subsystem on ls2k1000. 2) Explain why tiny drm driver is not suitable for us. 3) Give a short description of the trival dirty update implement based on CMA helper. v7: 1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now 2) Licensing issues are fixed suggested by Krzysztof Kozlowski. 3) Remove lsdc_pixpll_print(), part of it move to debugfs. 4) Set prefer_shadow to true if vram based driver is in using. 5) Replace double blank lines with single line in all files. 6) Verbose cmd line parameter is replaced with drm_dbg() 7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed 8) Get edid from dtb support is removed as suggested by Maxime Ripard 9) Fix typos and various improvement v8: 1) Drop damage update implement and its command line. 2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime. 3) Deduce DC's identification from its compatible property. 4) Drop the board specific dts patch. 5) Add documention about the display controller device node. v9: 1) Fix the warnings reported by checkpatch script and fix typos v10: 1) Pass `make dt_binding_check` validation 2) Fix warnings reported by kernel test robot v11: 1) Convert the driver to use drm bridge and of graph framework. 2) Dump register value support through debugfs. 3) Select DRM_TTM and DRM_TTM_HELPER in Kconfig which fix linkage problem when built it into the kernel. 4) Non 64 pixel(256 bytes aligned) horiziontal resolutons got supported by hacking, default is disabled, enable it by using 'loongson.relax_alignment=1' on kernel cmd line. 5) Various improvement as required by Maxime. v12: 1) Add gammma support, it is broken because hardware engineer does not implement this correctly. Using 'loongson.gamma=1' on the
[PATCH v15 4/6] MIPS: Loongson64: defconfig: enable display bridge drivers
ls3A4000 evb board ship with adv7123 and tfp410 while ls2k1000 PI board use a DPI panel from FORLINX company and a sii9022 HDMI transmitter. Signed-off-by: Sui Jingfeng <15330273...@189.cn> --- arch/mips/configs/loongson2k_defconfig | 5 + arch/mips/configs/loongson3_defconfig | 5 + 2 files changed, 10 insertions(+) diff --git a/arch/mips/configs/loongson2k_defconfig b/arch/mips/configs/loongson2k_defconfig index e948ca487e2d..0a97c332a5c3 100644 --- a/arch/mips/configs/loongson2k_defconfig +++ b/arch/mips/configs/loongson2k_defconfig @@ -243,6 +243,11 @@ CONFIG_MEDIA_USB_SUPPORT=y CONFIG_USB_VIDEO_CLASS=m CONFIG_DRM=y CONFIG_DRM_RADEON=y +CONFIG_DRM_DISPLAY_CONNECTOR=m +CONFIG_DRM_PANEL_SIMPLE=m +CONFIG_DRM_SII902X=m +CONFIG_DRM_SIMPLE_BRIDGE=m +CONFIG_DRM_TI_TFP410=m CONFIG_FB_RADEON=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=m diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 25ecd15bc952..35e2fc998768 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -280,6 +280,11 @@ CONFIG_MEDIA_USB_SUPPORT=y CONFIG_USB_VIDEO_CLASS=m CONFIG_DRM=y CONFIG_DRM_RADEON=m +CONFIG_DRM_DISPLAY_CONNECTOR=m +CONFIG_DRM_PANEL_SIMPLE=m +CONFIG_DRM_SII902X=m +CONFIG_DRM_SIMPLE_BRIDGE=m +CONFIG_DRM_TI_TFP410=m CONFIG_DRM_QXL=y CONFIG_DRM_VIRTIO_GPU=y CONFIG_FB=y -- 2.25.1
[PATCH v15 3/6] dt-bindings: display: Add Loongson display controller
This patch Add DT bindings and usages for Loongson display controller found in LS7A1000 bridge chip and LS2k1000 SoC. Signed-off-by: Sui Jingfeng <15330273...@189.cn> --- .../loongson/loongson,display-controller.yaml | 289 ++ 1 file changed, 289 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml new file mode 100644 index ..c89f19f3c698 --- /dev/null +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml @@ -0,0 +1,289 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings + +maintainers: + - Sui Jingfeng + +description: |+ + + Loongson display controllers are simple which require scanout buffers + to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system + memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped + with a dedicated video RAM which is 64MB or more, precise size can be + read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge + chip. + + LSDC has two display pipes, each way has a DVO interface which provide + RGB888 signals, vertical & horizontal synchronisations, data enable and + the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from + 1920x1080 resolution at 60Hz. Each CRTC has two FB address registers. + + For LS7A1000, there are 4 dedicated GPIOs whose control register is + located at the DC register space. They are used to emulate two way i2c, + One for DVO0, another for DVO1. + + LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either + general purpose GPIO emulated i2c or hardware i2c in the SoC. + + LSDC's display pipeline have several components as below description, + + The display controller in LS7A1000: + ___ _ +|---| | | +| CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor | +| _ _ ---|^ ^|_| +| | | | |---|| | +| |_| |_|| i2c0 <+-+ +|---| +| DC IN LS7A1000 | +| _ _ ---| +| | | | || i2c1 <+-+ +| |_| |_|---|| | _ +|---|| || | +| CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> | Panel | +|---| |_| +|___| + + Simple usage of LS7A1000 with LS3A4000 CPU: + ++--+++ +| DDR4 || +---+ | ++--+| | PCIe Root complex | LS7A1000 | + || MC0 | +--++-+++ | + +--+ HT 3.0 | || || | + | LS3A4000 |<>| +---++---+ +--++--+ +-+ +--+ + | CPU|<>| | GC1000 | | LSDC |<--->| DDR3 MC |<->| VRAM | + +--+ | ++ +-+--+-+ +-+ +--+ + || MC1 +---|--|-+ ++--+| | +| DDR4 | +---+ DVO0 | | DVO1 +--+ ++--+ VGA <--|ADV7125|<+ +>|TFP410|--> DVI/HDMI + +---+ +--+ + + The display controller in LS2K1000/LS2K0500: + ___ _ +|---| | | +| CRTC0 --> | DVO0 > Encoder0 ---> Connector0 ---> | Monitor | +| _ _ ---|^ ^ |_| +| | | | | || | +| |_| |_| | +--+ | +| <>| i2c0 |<-+ +| DC IN LS2K1000 | +--+ +| _ _| +--+ +| | | | | <>| i2c1 |--+ +| |_| |_| | +--+ |_ +|---|| | | | +| CRTC1 --> | DVO1 > Encoder1 ---> Connector1 ---> | Panel | +|---| |_| +|___| + +properties: + $nodename: +pattern: "^display-controller@[0-9a-f],[0-9a-f]$" +
[PATCH v15 2/6] MIPS: Loongson64: introduce board specific dts and add model property
This patch introduce three dts which are board specific and each of them is assigned a model property according to the board name printed on the top overlay of the PCB. The model property added can be used to provide board specific information, mips kernel use it as machine name. For example: $ cat /proc/cpuinfo system type : Generic Loongson64 System machine : LX-6901 < notice here processor : 0 cpu model : ICT Loongson-3 V0.1 FPU V0.1 BogoMIPS: 3594.02 tlb_entries : 2112 isa : mips64r2 ASEs implemented: vz msa loongson-ext2 ... 1) ls3A4000 evaluation board The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz mips64r5 4-core CPU and LS7A1000 bridge chip. It has a PCIe GEN2 x8 slot, therefore can play with discrete graphics card. While the integrated display copntroller is equipped with a VGA output and a DVI output, the VGA is connect to the DVO0 output port of the display controller, the DVI is connected to DVO1 output port of the display controller. +--++---+ | DDR4 || +---+| +--+| | PCIe Root complex | LS7A1000 | || MC0 | +--++-+++| +--+ HT 3.0 | || || | | LS3A4000 |<>| +---++---+ +--++--++-+ +--+ | CPU|<>| | GC1000 | | LSDC |<-->| DDR3 MC |<->| VRAM | +--+ | ++ +-+--+-++-+ +--+ || MC1 +---|--|+ +--+| | | DDR4 | +---+ DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<+ +>|TFP410|--> DVI/HDMI +---+ +--+ 2) lemote A1901 motherboard This board is made by LEMOTE corporation, it have two names, one is LX-6901, another is A1901. This board has only one VGA output which is connected to the DVO1 of the display controller. +--++---+ | DDR4 || +---+| +--+| | PCIe Root complex | LS7A1000 | || MC0 | +--++-+++| +--+ HT 3.0 | || || | | LS3A4000 |<>| +---++---+ +--++--++-+ +--+ | CPU|<>| | GC1000 | | LSDC |<-->| DDR3 MC |<->| VRAM | +--+ | ++ +-+--+-++-+ +--+ || MC1 +---|--|+ +--+| | | DDR4 | DVO0 is not get used | | DVO1 +---+ +--+ <+ +>|ADV7125|---> VGA +---+ 3) ls2k1000 pai evaluation board ls2k1000 is a two core 1.0Ghz Mips64r2 compatible SoC, despite very slow, a few display dridge drivers and display panel drivers can only be tested on this board. We provide a minimal support on this patch. ___ |---| || | CRTC0 --> | DVO0 > | 1024x600 DPI Panel | | _ _ ---| | Which panel to use || | | | | | | | with this board is a ___ | |_| |_| | | choice of the user | | | | +> | 800x480 DPI Panel | | DC In LS2K1000 | |___| | _ _| +--+ | | | | | <>| i2c1 |---+ | |_| |_| | +--+ | | || <--- config | DDC _ |---|+-+ | | | | CRTC1 --> | DVO1 ---> | sii9022 | --> HDMI connector --> | Monitor | |---|+-+|_| |___| The sii9022 HDMI transmitter working in transparent mode, because the PCB designer make the board working in this way. In this case the EDID is read from the monitor via the i2c1 directly, not through sii9022's ddc channel. The i2c0 is not get used by lsdc driver for this board. Signed-off-by: Sui Jingfeng <15330273...@189.cn> --- arch/mips/boot/dts/loongson/Makefile | 4 + arch/mips/boot/dts/loongson/lemote_a1901.dts | 96 .../boot/dts/loongson/ls2k1000_pai_udb.dts| 107 ++ .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 138 ++ 4 files changed, 345 insertions(+) create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dt
[PATCH v15 1/6] MIPS: Loongson64: dts: update the display controller device node
The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, its PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to the chip's
name.
For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space. They are used to emulate i2c for reading
edid from the monitor. One for DVO0, another for DVO1.
LS2K1000 and LS2K0500 SoC don't have such GPIOs, they grab i2c adapter
from other module, either general purpose GPIO emulated i2c or hardware
i2c adapter.
This patch add common part of the DC property only, it does not contain
ports property note. As it is for the generic boards which using
transparent encoder only.
Signed-off-by: Sui Jingfeng <15330273...@189.cn>
---
.../boot/dts/loongson/loongson64-2k1000.dtsi | 8 +++
arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 22 ++-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a6e3..2ecb5a232f22 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,14 @@ sata@8,0 {
interrupt-parent = <&liointc0>;
};
+ lsdc: display-controller@6,0 {
+ compatible = "loongson,ls2k1000-dc";
+
+ reg = <0x3000 0x0 0x0 0x0 0x0>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&liointc0>;
+ };
+
pci_bridge@9,0 {
compatible = "pci0014,7a19.0",
"pci0014,7a19",
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 2f45fce2cdc4..fcae7b20c5a2 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -160,15 +160,27 @@ gpu@6,0 {
interrupt-parent = <&pic>;
};
- dc@6,1 {
- compatible = "pci0014,7a06.0",
- "pci0014,7a06",
- "pciclass03",
- "pciclass0300";
+ lsdc: display-controller@6,1 {
+ compatible = "loongson,ls7a1000-dc";
reg = <0x3100 0x0 0x0 0x0 0x0>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&pic>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c6: i2c@6 {
+ compatible = "loongson,gpio-i2c";
+ loongson,sda = <0>;
+ loongson,scl = <1>;
+ };
+
+ i2c7: i2c@7 {
+ compatible = "loongson,gpio-i2c";
+ loongson,sda = <2>;
+ loongson,scl = <3>;
+ };
};
hda@7,0 {
--
2.25.1
[PATCH v15 0/6] drm/loongson: add drm driver for loongson display controller
There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge chip, the display controller is a PCI device. It have two display pipes but with only one hardware cursor. Each way has a DVO interface which provide RGB888 signals, vertical & horizontal synchronisations, data enable and the pixel clock. Each CRTC is able to drive a 1920x1080@60Hz monitor, the maxmium resolution is 2048x2048. Loongson display controllers are simple which require scanout buffers to be physically contiguous. For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM which is typically 64MB or more. In this case, VRAM helper based driver is intended to be used even through the DC can scanout form system memory. While LS2K1000 is a SoC which is a typically UMA device, only system memory is available. Therefore CMA helper based driver is intended to be used. It is possible to use VRAM helper based driver on LS2K1000 by carving out part of system memory as VRAM though. For LS7A1000, there are 4 dedicated GPIOs whose control registers is located at the DC register space, They are used to emulate two way i2c. One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such GPIO hardwared, they grab i2c adapter from other module, either general purpose GPIO emulated i2c or hardware i2c adapter. +--++---+ | DDR4 || +---+| +--+| | PCIe Root complex | LS7A1000 | || MC0 | +--++-+++| +--+ HT 3.0 | || || | | LS3A4000 |<>| +---++---+ +--++--++-+ +--+ | CPU|<>| | GC1000 | | LSDC |<-->| DDR3 MC |<->| VRAM | +--+ | ++ +-+--+-++-+ +--+ || MC1 +---|--|+ +--+| | | DDR4 | +---+ DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<+ +>|TFP410|--> DVI/HDMI +---+ +--+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, other candicates can be ch7034b, sil9022, ite66121 and lt8618 etc. Below is a brief introduction of loongson's CPU, bridge chip and SoC. LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[1]. LS7A1000 is a bridge chip made by Loongson corporation which act as north and/or south bridge of loongson's desktop and server level processor. It is equivalent to AMD RS780E+SB710 or something like that. More details can be read from its user manual[2]. This bridge chip is typically use with LS3A3000, LS3A4000 and LS3A5000 cpu. LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu. LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu[3]. LS3A5000 is 4 core 2.5gHz loongarch cpu[4]. Nearly all loongson cpu has the hardware maintain the cache coherency, this is the most distinct feature from other Mips cpu. [1] https://wiki.debian.org/InstallingDebianOn/Lemote/Loongson2K1000 [2] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanual-EN.html [3] https://ee-paper.com/loongson-3a4000-3b4000-motherboard-products-are-compatible-with-uos-system/ [4] https://loongson.github.io/LoongArch-Documentation/Loongson-3A5000-usermanual-EN.html [5] https://github.com/loongson-community/pmon Sui Jingfeng (6): MIPS: Loongson64: dts: update the display controller device node MIPS: Loongson64: introduce board specific dts and add model property dt-bindings: display: Add Loongson display controller MIPS: Loongson64: defconfig: enable display bridge drivers drm/loongson: add drm driver for loongson display controller MAINTAINERS: add maintainers for DRM LOONGSON driver .../loongson/loongson,display-controller.yaml | 289 + MAINTAINERS | 9 + arch/mips/boot/dts/loongson/Makefile | 4 + arch/mips/boot/dts/loongson/lemote_a1901.dts | 96 +++ .../boot/dts/loongson/loongson64-2k1000.dtsi | 8 + .../boot/dts/loongson/ls2k1000_pai_udb.dts| 107 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 138 + arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 22 +- arch/mips/configs/loongson2k_defconfig| 5 + arch/mips/configs/loongson3_defconfig | 5 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/loongson/Kconfig | 25 + drivers/gpu/drm/loongson/Makefile | 16 + drivers/gpu/drm/loongson/lsdc_crtc.c | 400 drivers/gpu/drm/loongson/lsdc_debugfs.c | 176 ++ drivers/gpu/drm/loongson/lsdc_debugfs.h | 17 + drivers/gpu/drm/loongson/lsdc_drv.c | 413 + drivers/gpu/drm/loongson/lsdc_drv.h | 186 ++ drivers/gpu/drm/loongson/lsd
Re: [PATCH v8 1/3] i915/gvt: Separate the MMIO tracking table from GVT-g
Hi Zhi, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip drm/drm-next next-20220401] [cannot apply to tegra-drm/drm/tegra/for-next airlied/drm-next v5.17] [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/intel-lab-lkp/linux/commits/Zhi-Wang/Refactor-GVT-g-MMIO-tracking-table-and-handlers/20220401-210319 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-c002 (https://download.01.org/0day-ci/archive/20220402/202204021603.w9au0c65-...@intel.com/config) compiler: gcc-11 (Debian 11.2.0-19) 11.2.0 reproduce (this is a W=1 build): # https://github.com/intel-lab-lkp/linux/commit/eeae6480610a35a271461e864f84540d6849d8d6 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Zhi-Wang/Refactor-GVT-g-MMIO-tracking-table-and-handlers/20220401-210319 git checkout eeae6480610a35a271461e864f84540d6849d8d6 # save the config file to linux build tree mkdir build_dir make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/ 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/i915/gvt/gvt.h:39, from drivers/gpu/drm/i915/gvt/mpt.h:36, from : drivers/gpu/drm/i915/intel_gvt.h:66:15: error: no previous prototype for 'intel_gvt_get_device_type' [-Werror=missing-prototypes] 66 | unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915) | ^ drivers/gpu/drm/i915/intel_gvt.h:71:41: error: 'struct intel_gvt_mmio_table_iter' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter) | ^ drivers/gpu/drm/i915/intel_gvt.h:71:5: error: no previous prototype for 'intel_gvt_iterate_mmio_table' [-Werror=missing-prototypes] 71 | int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter) | ^~~~ In file included from drivers/gpu/drm/i915/gvt/gvt.h:43, from drivers/gpu/drm/i915/gvt/mpt.h:36, from : >> drivers/gpu/drm/i915/gvt/mmio.h:74:15: error: conflicting types for >> 'intel_gvt_get_device_type'; have 'long unsigned int(struct intel_gvt *)' 74 | unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt); | ^ In file included from drivers/gpu/drm/i915/gvt/gvt.h:39, from drivers/gpu/drm/i915/gvt/mpt.h:36, from : drivers/gpu/drm/i915/intel_gvt.h:66:15: note: previous definition of 'intel_gvt_get_device_type' with type 'long unsigned int(struct drm_i915_private *)' 66 | unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915) | ^ cc1: all warnings being treated as errors vim +74 drivers/gpu/drm/i915/gvt/mmio.h 12d14cc43b34706 Zhi Wang 2016-08-30 71 8fde41076f6df53 Chris Wilson 2020-03-04 72 const struct intel_engine_cs * 8fde41076f6df53 Chris Wilson 2020-03-04 73 intel_gvt_render_mmio_to_engine(struct intel_gvt *gvt, unsigned int reg); 12d14cc43b34706 Zhi Wang 2016-08-30 @74 unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt); 12d14cc43b34706 Zhi Wang 2016-08-30 75 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [RFC][PATCH 2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()
Den 02.04.2022 06.28, skrev Marek Vasut: > On 4/2/22 05:19, Laurent Pinchart wrote: >> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote: >>> On 4/1/22 20:46, Laurent Pinchart wrote: On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote: > Make the width-mm/height-mm panel properties mandatory in > of_get_drm_panel_display_mode(), print error message and > return -ve in case these DT properties are not present. > This is needed to correctly report panel dimensions. Can we guarantee this won't cause a regression ? >>> >>> For the upstream DTs, I think we can. >>> For downstream DTs, we cannot know. >> >> Are there users of this function whose DT bindings don't require the >> width-mm and height-mm properties ? > > There is literally one user of this function upstream: > drivers/gpu/drm/tiny/panel-mipi-dbi.c Yes, the function was added for that driver since it was so generic in nature. What about adding an argument to of_get_drm_panel_display_mode() that tells if the properties are mandatory or not? Noralf.
