[drm-intel:topic/core-for-CI 2/20] kernel/locking/lockdep.c:2744:49: sparse: sparse: cast truncates bits from constant value (a0000 becomes 0)
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: d0435a9b45070b945578c093dcd363b6b73a502c
commit: cbc1ad45be43de36150fd98dae644fc89a69a5a0 [2/20] lockdep: Up
MAX_LOCKDEP_CHAINS
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-191-gc51a0382-dirty
git checkout cbc1ad45be43de36150fd98dae644fc89a69a5a0
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> kernel/locking/lockdep.c:2744:49: sparse: sparse: cast truncates bits from
>> constant value (a becomes 0)
>> kernel/locking/lockdep.c:2744:49: sparse: sparse: cast truncates bits from
>> constant value (a becomes 0)
vim +2744 kernel/locking/lockdep.c
810507fe6fd5ff Waiman Long 2020-02-06 2736
810507fe6fd5ff Waiman Long 2020-02-06 2737 static inline void
init_chain_block(int offset, int next, int bucket, int size)
810507fe6fd5ff Waiman Long 2020-02-06 2738 {
810507fe6fd5ff Waiman Long 2020-02-06 2739 chain_hlocks[offset] = (next >>
16) | CHAIN_BLK_FLAG;
810507fe6fd5ff Waiman Long 2020-02-06 2740 chain_hlocks[offset + 1] =
(u16)next;
810507fe6fd5ff Waiman Long 2020-02-06 2741
810507fe6fd5ff Waiman Long 2020-02-06 2742 if (size && !bucket) {
810507fe6fd5ff Waiman Long 2020-02-06 2743 chain_hlocks[offset +
2] = size >> 16;
810507fe6fd5ff Waiman Long 2020-02-06 @2744 chain_hlocks[offset +
3] = (u16)size;
810507fe6fd5ff Waiman Long 2020-02-06 2745 }
810507fe6fd5ff Waiman Long 2020-02-06 2746 }
810507fe6fd5ff Waiman Long 2020-02-06 2747
:: The code at line 2744 was first introduced by commit
:: 810507fe6fd5ff3de429121adff49523fabb643a locking/lockdep: Reuse freed
chain_hlocks entries
:: TO: Waiman Long
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Add hpd-gpios to the bindings
Hi, On Wed, Apr 15, 2020 at 5:54 PM Laurent Pinchart wrote: > > Hi Doug, > > On Wed, Apr 15, 2020 at 04:49:00PM -0700, Doug Anderson wrote: > > On Wed, Apr 15, 2020 at 1:33 PM Laurent Pinchart wrote: > > > On Wed, Apr 15, 2020 at 12:53:02PM -0700, Stephen Boyd wrote: > > > > Quoting Douglas Anderson (2020-04-15 08:48:40) > > > > > Allow people to specify to use a GPIO for hot-plug-detect. Add an > > > > > example. > > > > > > > > > > NOTE: The current patch adding support for hpd-gpios to the Linux > > > > > driver for hpd-gpios only adds enough support to the driver so that > > > > > the bridge can use one of its own GPIOs. The bindings, however, are > > > > > written generically. > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > --- > > > > > > > > > > .../bindings/display/bridge/ti,sn65dsi86.yaml | 10 > > > > > +- > > > > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > > > index 8cacc6db33a9..554bfd003000 100644 > > > > > --- > > > > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > > > +++ > > > > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > > > @@ -60,6 +60,10 @@ properties: > > > > > const: 1 > > > > > description: See ../../pwm/pwm.yaml for description of the cell > > > > > formats. > > > > > > > > > > + hpd-gpios: > > > > > +maxItems: 1 > > > > > +description: If present use the given GPIO for hot-plug-detect. > > > > > > > > Shouldn't this go in the panel node? And the panel driver should get the > > > > gpio and poll it after powering up the panel? Presumably that's why we > > > > have the no-hpd property in the simple panel binding vs. putting it here > > > > in the bridge. > > > > > > Same question really, I think this belongs to the panel (or connector) > > > node indeed. > > > > Hrm. > > > > To me "no-hpd" feels OK in the panel because the lack of a connection > > is somewhat symmetric. Thus it's OK to say either "HPD isn't hooked > > up to the panel in this system" or "HPD isn't hooked up to the bridge > > in this system" and both express the same thing (AKA that there is no > > HPD connection between the bridge and the panel). In the case of > > "no-hpd" it's more convenient to express it on the panel side because > > the panel driver is the one whose behavior has to change if HPD isn't > > hooked up. The panel datasheet is the one that says how long of a > > delay we need if HPD isn't hooked up. > > > > ...but when you're talking about where the bridge driver should look > > to find the HPD signal that it needs, that really feels like it should > > be described as part of the bridge. Specifically imagine we were > > using our bridge for DP, not for eDP. In that case simple-panel > > wouldn't be involved because we could get any type of display plugged > > in. Thus it couldn't go in the panel node. Here it feels clearer > > that hpd-gpio needs to be a property of the bridge driver. > > If you were using it for DP, you would need a DT node for the DP > connector (with bindings to be added to > Documentation/devicetree/bindings/display/connector/, similar to the > ones we already have for other connectors). That DT node should > reference the HPD pin GPIO. The bridge driver for the connector > (drivers/gpu/drm/bridge/display-connector.c) would then handle HPD. The > good news is that it already does :-) I'm having a really hard time following, but maybe it's because my knowledge of the DRM terminology is feeble at best? Looking at it from a DRM driver perspective and thus looking in 'drm/bridge/ti-sn65dsi86.c' I see that the driver for this bridge chip effectively is both the bridge and the connector. The struct encapsulating the driver data has both: struct drm_bridge bridge; struct drm_connector connector; ...in ti_sn_bridge_attach() the code calls drm_connector_init() for the connector. Looking at it from a device tree point of view, there is no separate node representing an eDP connector for one mainline user of 'ti,sn65dsi86' (sdm845-cheza). The device tree node has one input port (from "dsi0_out") and one output port (to "panel_in_edp"). There is no separate connector node as I can see with "hdmi-connector". ...and, as far as I can tell, sdm845-cheza is using the bindings as documented. The bindings say that the 'ti,sn65dsi86' node needs two ports: - Video port 0 for DSI input - Video port 1 for eDP output So, though I'm probably terribly confused, I would tentatively say that: - I'd guess that the 'ti,sn65dsi86' bindings were written / approved back before people were encouraged to model the connector as a separate node. - In the case of 'ti,sn65dsi86' the current dts node is both the node for the bridge and the connector. - If we want to try to
Re: [PATCH] drm/bridge: panel: Return always an error pointer in drm_panel_bridge_add()
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 11:06:54PM +0200, Enric Balletbo i Serra wrote:
> Since commit 89958b7cd955 ("drm/bridge: panel: Infer connector type from
> panel by default"), drm_panel_bridge_add() and their variants can return
> NULL and an error pointer. This is fine but none of the actual users of
> the API are checking for the NULL value. Instead of change all the
> users, seems reasonable to return an error pointer instead. So change
> the returned value for those functions when the connector type is unknown.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/gpu/drm/bridge/panel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 8461ee8304ba..7a3df0f319f3 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -166,7 +166,7 @@ static const struct drm_bridge_funcs
> panel_bridge_bridge_funcs = {
> *
> * The connector type is set to @panel->connector_type, which must be set to
> a
> * known type. Calling this function with a panel whose connector type is
> - * DRM_MODE_CONNECTOR_Unknown will return NULL.
> + * DRM_MODE_CONNECTOR_Unknown will return ERR_PTR(-EINVAL).
> *
> * See devm_drm_panel_bridge_add() for an automatically managed version of
> this
> * function.
> @@ -174,7 +174,7 @@ static const struct drm_bridge_funcs
> panel_bridge_bridge_funcs = {
> struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel)
> {
> if (WARN_ON(panel->connector_type == DRM_MODE_CONNECTOR_Unknown))
> - return NULL;
> + return ERR_PTR(-EINVAL);
>
> return drm_panel_bridge_add_typed(panel, panel->connector_type);
> }
> @@ -265,7 +265,7 @@ struct drm_bridge *devm_drm_panel_bridge_add(struct
> device *dev,
>struct drm_panel *panel)
> {
> if (WARN_ON(panel->connector_type == DRM_MODE_CONNECTOR_Unknown))
> - return NULL;
> + return ERR_PTR(-EINVAL);
>
> return devm_drm_panel_bridge_add_typed(dev, panel,
> panel->connector_type);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Enric,
On Thu, Apr 16, 2020 at 11:33:24PM +0200, Enric Balletbo i Serra wrote:
> On 16/4/20 19:36, Laurent Pinchart wrote:
> > On Thu, Apr 16, 2020 at 08:35:26PM +0300, Laurent Pinchart wrote:
> >> On Thu, Apr 16, 2020 at 05:57:19PM +0200, Enric Balletbo i Serra wrote:
> >>> Use the drm_bridge_connector helper to create a connector for pipelines
> >>> that use drm_bridge. This allows splitting connector operations across
> >>> multiple bridges when necessary, instead of having the last bridge in
> >>> the chain creating the connector and handling all connector operations
> >>> internally.
> >>
> >> That's the right direction, but this should be done in the mtk display
> >> controller driver core, not in here. I'm OK with the code being here as
> >> an interim measure if needed to move forward, but that should then be
> >> temporary only.
>
> It'd be nice if we can do this as an interim measure for now, so at least we
> have the embedded display working. IIUC to move that to the display controller
> driver core I should also convert/rework the mtk_dpi and mtk_hdmi drivers.
> This
> is used for the external display on my device but to fully support this I'll
> also need to rework the bridge chain logic to handle the
> multi-sink/multi-source
> use case. This is something I plan to work on but I suspect won't be easy and
> will trigger lots of discussions, and, of course, some time.
>
> So, if is fine I won't move this for now.
That's totally fine with me, I just wanted to make sure you were aware
that more work was needed :-)
Thanks for all your efforts !
> > I forgot to mention that the drm_encoder should also move out of the
> > bridge driver to the display controller driver.
> >
> >>> Signed-off-by: Enric Balletbo i Serra
> >>> ---
> >>>
> >>> Changes in v2: None
> >>>
> >>> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> index 44718fa3d1ca..2f8876c32864 100644
> >>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>> @@ -17,6 +17,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -184,6 +185,7 @@ struct mtk_dsi {
> >>> struct drm_bridge bridge;
> >>> struct drm_bridge *panel_bridge;
> >>> struct drm_bridge *next_bridge;
> >>> + struct drm_connector *connector;
> >>> struct phy *phy;
> >>>
> >>> void __iomem *regs;
> >>> @@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device
> >>> *drm, struct mtk_dsi *dsi)
> >>>*/
> >>> dsi->encoder.possible_crtcs = 1;
> >>>
> >>> - ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> >>> + ret = drm_bridge_attach(>encoder, >bridge, NULL,
> >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >>> if (ret)
> >>> goto err_cleanup_encoder;
> >>>
> >>> + dsi->connector = drm_bridge_connector_init(drm, >encoder);
> >>> + if (IS_ERR(dsi->connector)) {
> >>> + DRM_ERROR("Unable to create bridge connector\n");
> >>> + ret = PTR_ERR(dsi->connector);
> >>> + goto err_cleanup_encoder;
> >>> + }
> >>> + drm_connector_attach_encoder(dsi->connector, >encoder);
> >>> +
> >>> return 0;
> >>>
> >>> err_cleanup_encoder:
> >>> @@ -1144,6 +1155,7 @@ static int mtk_dsi_probe(struct platform_device
> >>> *pdev)
> >>>
> >>> dsi->bridge.funcs = _dsi_bridge_funcs;
> >>> dsi->bridge.of_node = dev->of_node;
> >>> + dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
> >>
> >> I think this line belongs to the patch that adds drm_bridge support to
> >> this driver.
> >>
> >>>
> >>> drm_bridge_add(>bridge);
> >>>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
Hi Dmitry, On Fri, Apr 17, 2020 at 12:15:33AM +0300, Dmitry Osipenko wrote: > 16.04.2020 23:50, Laurent Pinchart пишет: > > On Thu, Apr 16, 2020 at 11:21:40PM +0300, Dmitry Osipenko wrote: > >> 16.04.2020 21:52, Dmitry Osipenko пишет: > >> ... > May I also recommend switching to the DRM panel bridge helper ? It will > simplify the code. > >>> > >>> Could you please clarify what is the "DRM panel bridge helper"? > >>> > >>> I think we won't need any additional helpers after switching to the > >>> bridge connector helper, no? > >> > >> Actually, I now see that the panel needs to be manually attached to the > >> connector. > > > > The DRM panel bridge helper creates a bridge from a panel (with > > devm_drm_panel_bridge_add()). You can then attach that bridge to the > > chain, like any other bridge, and the enable/disable operations will be > > called automatically without any need to call the panel enable/disable > > manually as done currently. > > > >> Still it's not apparent to me how to get panel out of the bridge. It > >> looks like there is no such "panel helper" for the bridge API or I just > >> can't find it. > > > > You don't need to get a panel out of the bridge. You should get the > > bridge as done today, > > You mean "get the panel", correct? Yes, sorry. > > and wrap it in a bridge with > > devm_drm_panel_bridge_add(). > > > > The lvds-codec already wraps panel into the bridge using > devm_drm_panel_bridge_add() and chains it for us, please see > lvds_codec_probe() / lvds_codec_attach(). > > Does it mean that lvds-codec is not supporting the new model? No, that *is* the new model :-) As I think I've commented during review, when you have an LVDS encoder and a panel, you don't need to handle the panel at all. When you have an RGB panel connected directly to the RGB output, you need to wrap it in a bridge, exactly the same way as lvds-codec does for its panel. > Everything works nicely using the old model, where bridge creates > connector and attaches panel to it for us. > > [I'm still not sure what is the point to use the new model in a case of > a simple chain of bridges] > > Using the new model, the connector isn't created by the bridge, so I > need to duplicate that creation effort in the driver. Once the bridge > connector is manually created, I need to attach panel to this connector, > but panel is reachable only via the remote bridge (which wraps the panel). > > driver connector -> LVDS bridge -> panel bridge -> panel With the new model, 1. The display driver and the bridge drivers need to get hold of the bridge directly connected to their output (for instance with of_drm_find_panel()). If the output is connected to a panel, they need to wrap that panel in a bridge (with devm_drm_panel_bridge_add()). I plan, in the future, to make creation of panel bridges automatic, so drivers won't have to care. 2. The display driver needs to create a dummy drm_encoder for each of its outputs (for instance with drm_simple_encoder_init()). 3. The display driver needs to create a drm_connector for each of its outputs, and implement connector operations by delegating them to the bridges in the pipeline. Unless there's a good reason not to do so, this should be done with drm_bridge_connector_init(). That's it. Every driver then focusses on its own needs, bridge drivers handle only the device they're associated with, and the DRM core and DRM bridge connector helper will handle all the rest. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
Hi Dmitry, On Thu, Apr 16, 2020 at 11:21:40PM +0300, Dmitry Osipenko wrote: > 16.04.2020 21:52, Dmitry Osipenko пишет: > ... > >> May I also recommend switching to the DRM panel bridge helper ? It will > >> simplify the code. > > > > Could you please clarify what is the "DRM panel bridge helper"? > > > > I think we won't need any additional helpers after switching to the > > bridge connector helper, no? > > Actually, I now see that the panel needs to be manually attached to the > connector. The DRM panel bridge helper creates a bridge from a panel (with devm_drm_panel_bridge_add()). You can then attach that bridge to the chain, like any other bridge, and the enable/disable operations will be called automatically without any need to call the panel enable/disable manually as done currently. > Still it's not apparent to me how to get panel out of the bridge. It > looks like there is no such "panel helper" for the bridge API or I just > can't find it. You don't need to get a panel out of the bridge. You should get the bridge as done today, and wrap it in a bridge with devm_drm_panel_bridge_add(). -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/29] mm: only allow page table mappings for built-in zsmalloc
On Tue, Apr 14, 2020 at 03:13:30PM +0200, Christoph Hellwig wrote: > This allows to unexport map_vm_area and unmap_kernel_range, which are > rather deep internal and should not be available to modules, as they for > example allow fine grained control of mapping permissions, and also > allow splitting the setup of a vmalloc area and the actual mapping and > thus expose vmalloc internals. > > zsmalloc is typically built-in and continues to work (just like the > percpu-vm code using a similar patter), while modular zsmalloc also > continues to work, but must use copies. > > Signed-off-by: Christoph Hellwig > Acked-by: Peter Zijlstra (Intel) Acked-by: Minchan Kim Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
On Wed, 15 Apr 2020 10:35:08 +0200, "H. Nikolaus Schaller" wrote: > The Imagination PVR/SGX GPU is part of several SoC from > multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo, > Allwinner A83 and others. > > With this binding, we describe how the SGX processor is > interfaced to the SoC (registers, interrupt etc.). > > In most cases, Clock, Reset and power management is handled > by a parent node or elsewhere (e.g. code in the driver). > > Tested by make dt_binding_check dtbs_check > > Signed-off-by: H. Nikolaus Schaller > --- > .../devicetree/bindings/gpu/img,pvrsgx.yaml | 122 ++ > 1 file changed, 122 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml: while parsing a block mapping in "", line 74, column 13 did not find expected key in "", line 117, column 21 Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/gpu/img,pvrsgx.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/gpu/img,pvrsgx.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:1264: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1270997 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
Hi Christoph, Sorry for the late. On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote: > Hi Minchan, > > On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote: > > It doesn't mean we couldn't use zsmalloc as module any longer. It means > > we couldn't use zsmalloc as module with pgtable mapping whcih was little > > bit faster on microbenchmark in some architecutre(However, I usually temped > > to remove it since it had several problems). However, we could still use > > zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone > > really want to rollback the feature, they should provide reasonable reason > > why it doesn't work for them. "A little fast" wouldn't be enough to exports > > deep internal to the module. > > do you have any data how much faster it is on arm (and does that include > arm64 as well)? Besides the exports which were my prime concern, https://github.com/sjenning/zsmapbench I need to recall the memory. IIRC, it was almost 30% faster at that time in ARM so was not trivial at that time. However, it was story from several years ago. > zsmalloc with pgtable mappings also is the only user of map_kernel_range > outside of vmalloc.c, if it really is another code base for tiny > improvements we could mark map_kernel_range or in fact remove it entirely > and open code it in the remaining callers. I alsh have temped to remove it. Let me have time to revist it in this chance. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
Hi Dimitry. On Thu, Apr 16, 2020 at 11:21:40PM +0300, Dmitry Osipenko wrote: > 16.04.2020 21:52, Dmitry Osipenko пишет: > ... > >> May I also recommend switching to the DRM panel bridge helper ? It will > >> simplify the code. > > > > Could you please clarify what is the "DRM panel bridge helper"? > > > > I think we won't need any additional helpers after switching to the > > bridge connector helper, no? > > Actually, I now see that the panel needs to be manually attached to the > connector. > > Still it's not apparent to me how to get panel out of the bridge. It > looks like there is no such "panel helper" for the bridge API or I just > can't find it. Take a look in bridge/panel.c I think devm_drm_panel_bridge_add() is what you are after. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] AMDGPU: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
On Thu, Apr 16, 2020 at 4:07 PM Sandeep Raghuraman wrote:
>
> Initialize thermal controller fields in the PowerPlay table for Hawaii
> GPUs, so that fan speeds are reported.
>
> Signed-off-by: Sandeep Raghuraman
Applied. Thanks!
Alex
>
> ---
> .../drm/amd/powerplay/hwmgr/processpptables.c | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index 77c14671866c..bb58cfab1033 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -984,6 +984,34 @@ static int init_thermal_controller(
> struct pp_hwmgr *hwmgr,
> const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
> {
> + hwmgr->thermal_controller.ucType =
> + powerplay_table->sThermalController.ucType;
> + hwmgr->thermal_controller.ucI2cLine =
> + powerplay_table->sThermalController.ucI2cLine;
> + hwmgr->thermal_controller.ucI2cAddress =
> + powerplay_table->sThermalController.ucI2cAddress;
> +
> + hwmgr->thermal_controller.fanInfo.bNoFan =
> + (0 != (powerplay_table->sThermalController.ucFanParameters &
> + ATOM_PP_FANPARAMETERS_NOFAN));
> +
> + hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
> + powerplay_table->sThermalController.ucFanParameters &
> + ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
> +
> + hwmgr->thermal_controller.fanInfo.ulMinRPM
> + = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
> + hwmgr->thermal_controller.fanInfo.ulMaxRPM
> + = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
> +
> + set_hw_cap(
> + hwmgr,
> + ATOM_PP_THERMALCONTROLLER_NONE !=
> hwmgr->thermal_controller.ucType,
> + PHM_PlatformCaps_ThermalController
> + );
> +
> + hwmgr->thermal_controller.use_hw_fan_control = 1;
> +
> return 0;
> }
>
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
Hi Adrian,
[snip]
> >>
> >> +static void dw_mipi_dsi_get_hw_version(struct dw_mipi_dsi
> >> *dsi) +{ + regmap_read(dsi->regs, DSI_VERSION,
> >> >hw_version); + dsi->hw_version &= VERSION; +
> >> if (!dsi->hw_version) + dev_err(dsi->dev, "Failed
> >> to read DSI hw version register\n");
> >
> > Is this an error that should be ignored? If you can't get the HW
> > version, probably, there is something wrong with your hardware
> > so, don't you need to return an error?
> >
>
> After thinking a bit more about it, that error should be a
> warning.
>
> I added it because in some cases (for eg. if the peripheral clock
> is disabled) the reads can return 0 which is obviously an invalid
> version and the bridge will error in the next step when not
> finding a layout.
>
If you'll error anyway, why wait? IIUC at this point the clock *must*
be enabled, and if not, something is wrong with the driver, I don't
see any advantage on delay the error. do you have a use case where
this is called and peripheral clock disabled?
> So I'll make this a warning in v7 and explicitely mention that
> reads version == 0 can be caused by a disabled pclk.
>
-- Enric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] AMDGPU: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
Initialize thermal controller fields in the PowerPlay table for Hawaii
GPUs, so that fan speeds are reported.
Signed-off-by: Sandeep Raghuraman
---
.../drm/amd/powerplay/hwmgr/processpptables.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 77c14671866c..bb58cfab1033 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -984,6 +984,34 @@ static int init_thermal_controller(
struct pp_hwmgr *hwmgr,
const ATOM_PPLIB_POWERPLAYTABLE *powerplay_table)
{
+ hwmgr->thermal_controller.ucType =
+ powerplay_table->sThermalController.ucType;
+ hwmgr->thermal_controller.ucI2cLine =
+ powerplay_table->sThermalController.ucI2cLine;
+ hwmgr->thermal_controller.ucI2cAddress =
+ powerplay_table->sThermalController.ucI2cAddress;
+
+ hwmgr->thermal_controller.fanInfo.bNoFan =
+ (0 != (powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN));
+
+ hwmgr->thermal_controller.fanInfo.ucTachometerPulsesPerRevolution =
+ powerplay_table->sThermalController.ucFanParameters &
+ ATOM_PP_FANPARAMETERS_TACHOMETER_PULSES_PER_REVOLUTION_MASK;
+
+ hwmgr->thermal_controller.fanInfo.ulMinRPM
+ = powerplay_table->sThermalController.ucFanMinRPM * 100UL;
+ hwmgr->thermal_controller.fanInfo.ulMaxRPM
+ = powerplay_table->sThermalController.ucFanMaxRPM * 100UL;
+
+ set_hw_cap(
+ hwmgr,
+ ATOM_PP_THERMALCONTROLLER_NONE !=
hwmgr->thermal_controller.ucType,
+ PHM_PlatformCaps_ThermalController
+ );
+
+ hwmgr->thermal_controller.use_hw_fan_control = 1;
+
return 0;
}
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On 16.04.2020 20:21, Jason Gunthorpe wrote: > On Thu, Apr 16, 2020 at 11:12:56AM -0400, Nicolas Pitre wrote: >> On Thu, 16 Apr 2020, Arnd Bergmann wrote: >> >>> On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula >>> wrote: On Thu, 16 Apr 2020, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed > wrote: >> BTW how about adding a new Kconfig option to hide the details of >> ( BAR || !BAR) ? as Jason already explained and suggested, this will >> make it easier for the users and developers to understand the actual >> meaning behind this tristate weird condition. >> >> e.g have a new keyword: >> reach VXLAN >> which will be equivalent to: >> depends on VXLAN && !VXLAN > I'd love to see that, but I'm not sure what keyword is best. For your > suggestion of "reach", that would probably do the job, but I'm not > sure if this ends up being more or less confusing than what we have > today. Ah, perfect bikeshedding topic! Perhaps "uses"? If the dependency is enabled it gets used as a dependency. >>> That seems to be the best naming suggestion so far >> What I don't like about "uses" is that it doesn't convey the conditional >> dependency. It could be mistaken as being synonymous to "select". >> >> What about "depends_if" ? The rationale is that this is actually a >> dependency, but only if the related symbol is set (i.e. not n or empty). > I think that stretches the common understanding of 'depends' a bit too > far.. A depends where the target can be N is just too strange. > > Somthing incorporating 'optional' seems like a better choice > 'optionally uses' seems particularly clear and doesn't overload > existing works like depends or select I think the whole misunderstanding with imply is that ppl try to use it as weak 'depend on' but it is weak 'select' - ie it enforces value of implied symbol in contrast to 'depends' which enforces value of current symbol. So if we want to add new symbol 'weak depend' it would be good to stress out that difference. Moreover name imply is already cryptic, adding another keyword which for sure will be cryptic (as there are no natural candidates) will complicate things more. Maybe adding some decorator would be better, like optionally or weak, for example: optionally depends on X optionally select Y Even more readable: depends on X if on depends on Y if enabled Regards Andrzej > > Jason > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH trivial 1/6] dt-bindings: Fix misspellings of "Analog Devices"
On Thu, 16 Apr 2020 12:30:53 +0200, Geert Uytterhoeven wrote: > According to https://www.analog.com/, the company name is spelled > "Analog Devices". > > Signed-off-by: Geert Uytterhoeven > --- > .../devicetree/bindings/display/bridge/adi,adv7123.txt| 4 ++-- > .../devicetree/bindings/display/bridge/adi,adv7511.txt| 4 ++-- > Documentation/devicetree/bindings/dma/adi,axi-dmac.txt| 2 +- > Documentation/devicetree/bindings/iio/dac/ad5755.txt | 2 +- > 4 files changed, 6 insertions(+), 6 deletions(-) > Applied, thanks. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/5] drm/amdgpu: utilize subconnector property for DP through atombios
On Thu, 16 Apr 2020, Alex Deucher wrote:
> On Wed, Apr 15, 2020 at 6:05 AM Jani Nikula wrote:
>>
>>
>> Alex, Harry, Christian, can you please eyeball this series and see if it
>> makes sense for you?
>>
>
> Patches 4, 5 are:
> Acked-by: Alex Deucher
> Feel free to take them through whichever tree you want.
Thanks a bunch! I'll let you know.
BR,
Jani.
>
> Alex
>
>
>> Thanks,
>> Jani.
>>
>>
>> On Tue, 07 Apr 2020, Jeevan B wrote:
>> > From: Oleg Vasilev
>> >
>> > Since DP-specific information is stored in driver's structures, every
>> > driver needs to implement subconnector property by itself.
>> >
>> > v2: rebase
>> >
>> > Cc: Alex Deucher
>> > Cc: Christian König
>> > Cc: David (ChunMing) Zhou
>> > Cc: amd-...@lists.freedesktop.org
>> > Signed-off-by: Jeevan B
>> > Signed-off-by: Oleg Vasilev
>> > Reviewed-by: Emil Velikov
>> > Link:
>> > https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-6-oleg.vasi...@intel.com
>> > ---
>> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 ++
>> > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
>> > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 18 +-
>> > 3 files changed, 28 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> > index f355d9a..71aade0 100644
>> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> > @@ -26,6 +26,7 @@
>> >
>> > #include
>> > #include
>> > +#include
>> > #include
>> > #include
>> > #include "amdgpu.h"
>> > @@ -1405,6 +1406,10 @@ amdgpu_connector_dp_detect(struct drm_connector
>> > *connector, bool force)
>> > pm_runtime_put_autosuspend(connector->dev->dev);
>> > }
>> >
>> > + drm_dp_set_subconnector_property(_connector->base,
>> > + ret,
>> > + amdgpu_dig_connector->dpcd,
>> > +
>> > amdgpu_dig_connector->downstream_ports);
>> > return ret;
>> > }
>> >
>> > @@ -1951,6 +1956,11 @@ amdgpu_connector_add(struct amdgpu_device *adev,
>> > if (has_aux)
>> > amdgpu_atombios_dp_aux_init(amdgpu_connector);
>> >
>> > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>> > + connector_type == DRM_MODE_CONNECTOR_eDP) {
>> > +
>> > drm_mode_add_dp_subconnector_property(_connector->base);
>> > + }
>> > +
>> > return;
>> >
>> > failed:
>> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
>> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
>> > index 37ba07e..04a430e 100644
>> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
>> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
>> > @@ -469,6 +469,7 @@ struct amdgpu_encoder {
>> > struct amdgpu_connector_atom_dig {
>> > /* displayport */
>> > u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> > + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
>> > u8 dp_sink_type;
>> > int dp_clock;
>> > int dp_lane_count;
>> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
>> > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
>> > index 9b74cfd..900b272 100644
>> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
>> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
>> > @@ -328,6 +328,22 @@ static void amdgpu_atombios_dp_probe_oui(struct
>> > amdgpu_connector *amdgpu_connect
>> > buf[0], buf[1], buf[2]);
>> > }
>> >
>> > +static void amdgpu_atombios_dp_ds_ports(struct amdgpu_connector
>> > *amdgpu_connector)
>> > +{
>> > + struct amdgpu_connector_atom_dig *dig_connector =
>> > amdgpu_connector->con_priv;
>> > + int ret;
>> > +
>> > + if (dig_connector->dpcd[DP_DPCD_REV] > 0x10) {
>> > + ret = drm_dp_dpcd_read(_connector->ddc_bus->aux,
>> > +DP_DOWNSTREAM_PORT_0,
>> > +dig_connector->downstream_ports,
>> > +DP_MAX_DOWNSTREAM_PORTS);
>> > + if (ret)
>> > + memset(dig_connector->downstream_ports, 0,
>> > +DP_MAX_DOWNSTREAM_PORTS);
>> > + }
>> > +}
>> > +
>> > int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector *amdgpu_connector)
>> > {
>> > struct amdgpu_connector_atom_dig *dig_connector =
>> > amdgpu_connector->con_priv;
>> > @@ -343,7 +359,7 @@ int amdgpu_atombios_dp_get_dpcd(struct
>> > amdgpu_connector *amdgpu_connector)
>> > dig_connector->dpcd);
>> >
>> > amdgpu_atombios_dp_probe_oui(amdgpu_connector);
>> > -
>> > + amdgpu_atombios_dp_ds_ports(amdgpu_connector);
>> > return 0;
>> > }
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
>> ___
>> dri-devel mailing list
>>
Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
On Wed, 15 Apr 2020, Enric Balletbo Serra
wrote:
Hi Adrian,
Some few comments/nits below,
Missatge de Adrian Ratiu del dia
dt., 14 d’abr. 2020 a les 17:19:
In order to support multiple versions of the Synopsis MIPI DSI
host controller, which have different register layouts but
almost identical HW protocols, we add a regmap infrastructure
which can abstract away register accesses for platform drivers
using the bridge.
The controller HW revision is detected during bridge probe
which will be used in future commits to load the relevant
register layout which the bridge will use transparently to the
platform drivers.
Suggested-by: Ezequiel Garcia
Tested-by: Adrian Pop Tested-by:
Arnaud Ferraris Signed-off-by:
Adrian Ratiu --- New in v5. ---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 208
++ 1 file changed, 117 insertions(+), 91
deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
5ef0f154aa7b..6d9e2f21c9cc 100644 ---
a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -15,6 +15,7
@@
#include #include
#include
+#include
Should Kconfig select REGMAP for this driver?
#include
#include
@@ -227,6 +228,7 @@ struct dw_mipi_dsi {
struct drm_bridge *panel_bridge; struct device *dev;
void __iomem *base;
+ struct regmap *regs;
struct clk *pclk;
@@ -235,6 +237,7 @@ struct dw_mipi_dsi {
u32 lanes; u32 format; unsigned long mode_flags;
+ u32 hw_version;
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
@@ -249,6 +252,13 @@ struct dw_mipi_dsi {
const struct dw_mipi_dsi_plat_data *plat_data;
};
+static const struct regmap_config dw_mipi_dsi_regmap_cfg = { +
.reg_bits = 32, + .val_bits = 32, + .reg_stride =
4, + .name = "dw-mipi-dsi", +}; +
/*
* Check if either a link to a master or slave is present */
@@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi
*bridge_to_dsi(struct drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi,
bridge);
}
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg,
u32 val) -{ - writel(val, dsi->base + reg); -} - -static
inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg) -{ -
return readl(dsi->base + reg); -} -
static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device
*device)
{
@@ -366,29 +366,29 @@ static void dw_mipi_message_config(struct
dw_mipi_dsi *dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
- dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 :
PHY_TXREQUESTCLKHS); - dsi_write(dsi, DSI_CMD_MODE_CFG,
val); + regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 :
PHY_TXREQUESTCLKHS); + regmap_write(dsi->regs,
DSI_CMD_MODE_CFG, val);
}
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi
*dsi, u32 hdr_val) {
int ret;
- u32 val, mask; + u32 val = 0, mask;
I think that this change is not needed, `val` is an input
variable that will be overwritten inside the
regmap_read_poll_timeout. Initialize here is not needed.
- ret = readl_poll_timeout(dsi->base +
DSI_CMD_PKT_STATUS, -val, !(val
& GEN_CMD_FULL), 1000, -
CMD_PKT_STATUS_TIMEOUT_US); + ret =
regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS, +
val, !(val & GEN_CMD_FULL), 1000, +
CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available
command FIFO\n"); return ret;
}
- dsi_write(dsi, DSI_GEN_HDR, hdr_val); +
regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
- ret = readl_poll_timeout(dsi->base +
DSI_CMD_PKT_STATUS, -val, (val
& mask) == mask, -1000,
CMD_PKT_STATUS_TIMEOUT_US); + ret =
regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS, +
val, (val & mask) == mask, +
1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command
FIFO\n"); return ret;
@@ -403,24 +403,26 @@ static int dw_mipi_dsi_write(struct
dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload; int len =
packet->payload_length, pld_data_bytes = sizeof(u32),
ret; __le32 word;
- u32 val; + u32 val = 0;
The same here, 'val' is used for the regmap_read_poll_timeout
and will be overwritten, no need to initialize.
while (len) {
if (len < pld_data_bytes) {
word = 0; memcpy(, tx_buf, len);
- dsi_write(dsi, DSI_GEN_PLD_DATA,
le32_to_cpu(word)); +
regmap_write(dsi->regs, DSI_GEN_PLD_DATA, +
Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
On Wed, 15 Apr 2020, Enric Balletbo Serra
wrote:
Hi Adrian,
Some few comments/nits below,
Hi Enric,
Thank you for your review, all your suggested changes will be part
of v7. I have only one minor comment below.
Missatge de Adrian Ratiu del dia
dt., 14 d’abr. 2020 a les 17:19:
In order to support multiple versions of the Synopsis MIPI DSI
host controller, which have different register layouts but
almost identical HW protocols, we add a regmap infrastructure
which can abstract away register accesses for platform drivers
using the bridge.
The controller HW revision is detected during bridge probe
which will be used in future commits to load the relevant
register layout which the bridge will use transparently to the
platform drivers.
Suggested-by: Ezequiel Garcia
Tested-by: Adrian Pop Tested-by:
Arnaud Ferraris Signed-off-by:
Adrian Ratiu --- New in v5. ---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 208
++ 1 file changed, 117 insertions(+), 91
deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
5ef0f154aa7b..6d9e2f21c9cc 100644 ---
a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -15,6 +15,7
@@
#include #include
#include
+#include
Should Kconfig select REGMAP for this driver?
#include
#include
@@ -227,6 +228,7 @@ struct dw_mipi_dsi {
struct drm_bridge *panel_bridge; struct device *dev;
void __iomem *base;
+ struct regmap *regs;
struct clk *pclk;
@@ -235,6 +237,7 @@ struct dw_mipi_dsi {
u32 lanes; u32 format; unsigned long mode_flags;
+ u32 hw_version;
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
@@ -249,6 +252,13 @@ struct dw_mipi_dsi {
const struct dw_mipi_dsi_plat_data *plat_data;
};
+static const struct regmap_config dw_mipi_dsi_regmap_cfg = { +
.reg_bits = 32, + .val_bits = 32, + .reg_stride =
4, + .name = "dw-mipi-dsi", +}; +
/*
* Check if either a link to a master or slave is present */
@@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi
*bridge_to_dsi(struct drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi,
bridge);
}
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg,
u32 val) -{ - writel(val, dsi->base + reg); -} - -static
inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg) -{ -
return readl(dsi->base + reg); -} -
static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device
*device)
{
@@ -366,29 +366,29 @@ static void dw_mipi_message_config(struct
dw_mipi_dsi *dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
- dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 :
PHY_TXREQUESTCLKHS); - dsi_write(dsi, DSI_CMD_MODE_CFG,
val); + regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 :
PHY_TXREQUESTCLKHS); + regmap_write(dsi->regs,
DSI_CMD_MODE_CFG, val);
}
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi
*dsi, u32 hdr_val) {
int ret;
- u32 val, mask; + u32 val = 0, mask;
I think that this change is not needed, `val` is an input
variable that will be overwritten inside the
regmap_read_poll_timeout. Initialize here is not needed.
- ret = readl_poll_timeout(dsi->base +
DSI_CMD_PKT_STATUS, -val, !(val
& GEN_CMD_FULL), 1000, -
CMD_PKT_STATUS_TIMEOUT_US); + ret =
regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS, +
val, !(val & GEN_CMD_FULL), 1000, +
CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available
command FIFO\n"); return ret;
}
- dsi_write(dsi, DSI_GEN_HDR, hdr_val); +
regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
- ret = readl_poll_timeout(dsi->base +
DSI_CMD_PKT_STATUS, -val, (val
& mask) == mask, -1000,
CMD_PKT_STATUS_TIMEOUT_US); + ret =
regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS, +
val, (val & mask) == mask, +
1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command
FIFO\n"); return ret;
@@ -403,24 +403,26 @@ static int dw_mipi_dsi_write(struct
dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload; int len =
packet->payload_length, pld_data_bytes = sizeof(u32),
ret; __le32 word;
- u32 val; + u32 val = 0;
The same here, 'val' is used for the regmap_read_poll_timeout
and will be overwritten, no need to initialize.
while (len) {
if (len < pld_data_bytes) {
word = 0; memcpy(, tx_buf, len);
Re: [PATCH v3 1/2] drm/tegra: output: Don't leak OF node on error
Hi Dmitry, On Thu, Apr 16, 2020 at 08:30:24PM +0300, Dmitry Osipenko wrote: > 16.04.2020 20:27, Laurent Pinchart пишет: > > On Thu, Apr 16, 2020 at 08:24:04PM +0300, Dmitry Osipenko wrote: > >> The OF node should be put before returning error in tegra_output_probe(), > >> otherwise node's refcount will be leaked. > >> > >> Signed-off-by: Dmitry Osipenko > > > > Reviewed-by: Laurent Pinchart > > Hello Laurent, > > That is the fastest kernel review I ever got, thank you :) I think I'm also guilty for the slowest kernel reviews ever, so maybe in the end it will even out :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
Hi Dmitry,
Thank you for the patch.
On Thu, Apr 16, 2020 at 08:24:05PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph that involves
> LVDS encoder bridge, This patch adds support for the LVDS encoder bridge
> to the RGB output, allowing us to model display hardware properly.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/drm.h| 2 ++
> drivers/gpu/drm/tegra/output.c | 10 ++
> drivers/gpu/drm/tegra/rgb.c| 34 ++
> 3 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 804869799305..cccd368b6752 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -12,6 +12,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -116,6 +117,7 @@ struct tegra_output {
> struct device_node *of_node;
> struct device *dev;
>
> + struct drm_bridge *bridge;
> struct drm_panel *panel;
> struct i2c_adapter *ddc;
> const struct edid *edid;
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index a6a711d54e88..37fc6b8c173f 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -180,6 +180,16 @@ int tegra_output_init(struct drm_device *drm, struct
> tegra_output *output)
> int connector_type;
> int err;
>
> + if (output->bridge) {
> + err = drm_bridge_attach(>encoder, output->bridge,
> + NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
Using DRM_BRIDGE_ATTACH_NO_CONNECTOR is definitely the way to go, but
please be aware that it will require creating a connector and an encoder
manually (which I think this driver already does), and using the bridge
operations to implement the connector operations. I highly recommend
using the DRM bridge connector helper for this purpose.
> + if (err) {
> + dev_err(output->dev, "cannot connect bridge: %d\n",
> + err);
> + return err;
> + }
> + }
> +
> if (output->panel) {
May I also recommend switching to the DRM panel bridge helper ? It will
simplify the code.
> err = drm_panel_attach(output->panel, >connector);
> if (err < 0)
> diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
> index 0562a7eb793f..0df213e92664 100644
> --- a/drivers/gpu/drm/tegra/rgb.c
> +++ b/drivers/gpu/drm/tegra/rgb.c
> @@ -5,6 +5,7 @@
> */
>
> #include
> +#include
>
> #include
> #include
> @@ -210,6 +211,7 @@ static const struct drm_encoder_helper_funcs
> tegra_rgb_encoder_helper_funcs = {
>
> int tegra_dc_rgb_probe(struct tegra_dc *dc)
> {
> + const unsigned int encoder_port = 0, panel_port = 1;
> struct device_node *np;
> struct tegra_rgb *rgb;
> int err;
> @@ -226,6 +228,38 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc)
> rgb->output.of_node = np;
> rgb->dc = dc;
>
> + /*
> + * Tegra devices that have LVDS panel utilize LVDS-encoder bridge
> + * for converting 24/18 RGB data-lanes into 8 lanes. Encoder usually
> + * have a powerdown control which needs to be enabled in order to
> + * transfer data to the panel. Historically devices that use an older
> + * device-tree version didn't model the bridge, assuming that encoder
> + * is turned ON by default, while today's DRM allows us to model LVDS
> + * encoder properly.
> + *
> + * Newer device-trees may utilize output->encoder->panel graph.
> + *
> + * For older device-trees we fall back to use nvidia,panel phandle.
> + */
> + np = of_graph_get_remote_node(rgb->output.of_node, encoder_port, -1);
> + if (np) {
> + rgb->output.bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!rgb->output.bridge)
> + return -EPROBE_DEFER;
> +
> + np = of_graph_get_remote_node(rgb->output.bridge->of_node,
> + panel_port, -1);
This shouldn't be needed, the LVDS codec bridge driver should already
get the panel and handle it internally. You only need to handle panels
in this driver when they're connected directly to the RGB input.
> + if (np) {
> + rgb->output.panel = of_drm_find_panel(np);
> + of_node_put(np);
> +
> + if (IS_ERR(rgb->output.panel))
> + return PTR_ERR(rgb->output.panel);
> + }
> + }
> +
> err = tegra_output_probe(>output);
> if (err < 0)
> return err;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: android: ion: Skip sync if not mapped
Great! Thanks! regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Enric,
On Thu, Apr 16, 2020 at 08:35:26PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 16, 2020 at 05:57:19PM +0200, Enric Balletbo i Serra wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multiple bridges when necessary, instead of having the last bridge in
> > the chain creating the connector and handling all connector operations
> > internally.
>
> That's the right direction, but this should be done in the mtk display
> controller driver core, not in here. I'm OK with the code being here as
> an interim measure if needed to move forward, but that should then be
> temporary only.
I forgot to mention that the drm_encoder should also move out of the
bridge driver to the display controller driver.
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> > Changes in v2: None
> >
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 44718fa3d1ca..2f8876c32864 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -17,6 +17,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -184,6 +185,7 @@ struct mtk_dsi {
> > struct drm_bridge bridge;
> > struct drm_bridge *panel_bridge;
> > struct drm_bridge *next_bridge;
> > + struct drm_connector *connector;
> > struct phy *phy;
> >
> > void __iomem *regs;
> > @@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device
> > *drm, struct mtk_dsi *dsi)
> > */
> > dsi->encoder.possible_crtcs = 1;
> >
> > - ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> > + ret = drm_bridge_attach(>encoder, >bridge, NULL,
> > + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > if (ret)
> > goto err_cleanup_encoder;
> >
> > + dsi->connector = drm_bridge_connector_init(drm, >encoder);
> > + if (IS_ERR(dsi->connector)) {
> > + DRM_ERROR("Unable to create bridge connector\n");
> > + ret = PTR_ERR(dsi->connector);
> > + goto err_cleanup_encoder;
> > + }
> > + drm_connector_attach_encoder(dsi->connector, >encoder);
> > +
> > return 0;
> >
> > err_cleanup_encoder:
> > @@ -1144,6 +1155,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> >
> > dsi->bridge.funcs = _dsi_bridge_funcs;
> > dsi->bridge.of_node = dev->of_node;
> > + dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
>
> I think this line belongs to the patch that adds drm_bridge support to
> this driver.
>
> >
> > drm_bridge_add(>bridge);
> >
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix page flip ioctl format check
On Thu, Apr 16, 2020 at 08:08:14PM +0300, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Revert back to comparing fb->format->format instead fb->format for the
> > page flip ioctl. This check was originally only here to disallow pixel
> > format changes, but when we changed it to do the pointer comparison
> > we potentially started to reject some (but definitely not all) modifier
> > changes as well. In fact the current behaviour depends on whether the
> > driver overrides the format info for a specific format+modifier combo.
> > Eg. on i915 this now rejects compression vs. no compression changes but
> > does not reject any other tiling changes. That's just inconsistent
> > nonsense.
> >
> > The main reason we have to go back to the old behaviour is to fix page
> > flipping with Xorg. At some point Xorg got its atomic rights taken away
> > and since then we can't page flip between compressed and non-compressed
> > fbs on i915. Currently we get no page flipping for any games pretty much
> > since Mesa likes to use compressed buffers. Not sure how compositors are
> > working around this (don't use one myself). I guess they must be doing
> > something to get non-compressed buffers instead. Either that or
> > somehow no one noticed the tearing from the blit fallback.
> >
> > Looking back at the original discussion on this change we pretty much
> > just did it in the name of skipping a few extra pointer dereferences.
> > However, I've decided not to revert the whole thing in case someone
> > has since started to depend on these changes. None of the other checks
> > are relevant for i915 anyways.
>
> Do display controller usually support changing modifiers for page flips
> ? I understand from the information about that i915 does, but is that
> usual ? Could there be drivers that really on this check to reject
> modifier changes, and that aren't prepared to handle them if they are
> not rejected by the core ? I'm not opposed to this change, but I'd like
> to carefully consider the fallout.
After a bit of grepping I can't actually see any other driver providing
a .get_format_info() hook. So looks like there is no change in behaviour
for any other driver. Based on that we could even do a full revert, but
meh.
>
> > Cc: sta...@vger.kernel.org
> > Cc: Laurent Pinchart
> > Fixes: dbd4d5761e1f ("drm: Replace 'format->format' comparisons to just
> > 'format' comparisons")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index d6ad60ab0d38..f2ca5315f23b 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1153,7 +1153,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > if (ret)
> > goto out;
> >
> > - if (old_fb->format != fb->format) {
> > + if (old_fb->format->format != fb->format->format) {
> > DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
> > format.\n");
> > ret = -EINVAL;
> > goto out;
>
> --
> Regards,
>
> Laurent Pinchart
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 05:57:19PM +0200, Enric Balletbo i Serra wrote:
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
That's the right direction, but this should be done in the mtk display
controller driver core, not in here. I'm OK with the code being here as
an interim measure if needed to move forward, but that should then be
temporary only.
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 44718fa3d1ca..2f8876c32864 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -184,6 +185,7 @@ struct mtk_dsi {
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> struct drm_bridge *next_bridge;
> + struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
>*/
> dsi->encoder.possible_crtcs = 1;
>
> - ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> + ret = drm_bridge_attach(>encoder, >bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> + dsi->connector = drm_bridge_connector_init(drm, >encoder);
> + if (IS_ERR(dsi->connector)) {
> + DRM_ERROR("Unable to create bridge connector\n");
> + ret = PTR_ERR(dsi->connector);
> + goto err_cleanup_encoder;
> + }
> + drm_connector_attach_encoder(dsi->connector, >encoder);
> +
> return 0;
>
> err_cleanup_encoder:
> @@ -1144,6 +1155,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>
> dsi->bridge.funcs = _dsi_bridge_funcs;
> dsi->bridge.of_node = dev->of_node;
> + dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
I think this line belongs to the patch that adds drm_bridge support to
this driver.
>
> drm_bridge_add(>bridge);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 05:57:18PM +0200, Enric Balletbo i Serra wrote:
> Replace the manual panel handling code by a drm_panel_bridge. This
> simplifies the driver and allows all components in the display pipeline
> to be treated as bridges, paving the way to generic connector handling.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 177 -
> 1 file changed, 19 insertions(+), 158 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 48361c1e9f34..44718fa3d1ca 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,8 +182,7 @@ struct mtk_dsi {
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> - struct drm_connector conn;
> - struct drm_panel *panel;
> + struct drm_bridge *panel_bridge;
I think you can use the next_bridge field to store the panel bridge, it
will simplify the code a bit in mtk_dsi_bridge_attach().
> struct drm_bridge *next_bridge;
> struct phy *phy;
>
> @@ -212,11 +211,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
> drm_bridge *b)
> return container_of(b, struct mtk_dsi, bridge);
> }
>
> -static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> -{
> - return container_of(c, struct mtk_dsi, conn);
> -}
> -
> static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
> {
> return container_of(h, struct mtk_dsi, host);
> @@ -682,16 +676,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to prepare the panel\n");
> - goto err_disable_digital_clk;
> - }
> - }
> -
> return 0;
> -err_disable_digital_clk:
> - clk_disable_unprepare(dsi->digital_clk);
> err_disable_engine_clk:
> clk_disable_unprepare(dsi->engine_clk);
> err_phy_power_off:
> @@ -718,15 +703,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>*/
> mtk_dsi_stop(dsi);
>
> - if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> - if (dsi->panel) {
> - if (drm_panel_unprepare(dsi->panel)) {
> - DRM_ERROR("failed to unprepare the panel\n");
> - return;
> - }
> - }
> - }
> -
> + mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
> mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
> @@ -757,19 +734,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>
> mtk_dsi_start(dsi);
>
> - if (dsi->panel) {
> - if (drm_panel_enable(dsi->panel)) {
> - DRM_ERROR("failed to enable the panel\n");
> - goto err_dsi_power_off;
> - }
> - }
> -
> dsi->enabled = true;
> -
> - return;
> -err_dsi_power_off:
> - mtk_dsi_stop(dsi);
> - mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> @@ -777,34 +742,24 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> if (!dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_disable(dsi->panel)) {
> - DRM_ERROR("failed to disable the panel\n");
> - return;
> - }
> - }
> -
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
> }
>
> -static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> -static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> -
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> + struct drm_bridge *next;
>
> - return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> -}
> -
> -static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> -{
> - struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> + if (dsi->next_bridge)
> + next = dsi->next_bridge;
> + else
> + next = dsi->panel_bridge;
>
> - mtk_dsi_destroy_conn_enc(dsi);
> + /* Attach the panel or bridge to the dsi bridge */
> + return drm_bridge_attach(bridge->encoder, next, >bridge, flags);
> }
>
> static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> @@ -830,101 +785,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
> *bridge)
> mtk_output_dsi_enable(dsi);
> }
>
> -static int mtk_dsi_connector_get_modes(struct
Re: [PATCH v2 5/7] drm/mediatek: mtk_dsi: Use simple encoder
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 05:57:17PM +0200, Enric Balletbo i Serra wrote:
> The mtk_dsi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 3400d6686c85..48361c1e9f34 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_drm_ddp_comp.h"
>
> @@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
> }
>
> -static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> - .destroy = mtk_dsi_encoder_destroy,
> -};
> -
> static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>
> @@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> {
> int ret;
>
> - ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
> -DRM_MODE_ENCODER_DSI, NULL);
> + ret = drm_simple_encoder_init(drm, >encoder,
> + DRM_MODE_ENCODER_DSI);
> if (ret) {
> DRM_ERROR("Failed to encoder init to drm\n");
> return ret;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/tegra: output: Don't leak OF node on error
Hi Dmitry,
Thank you for the patch.
On Thu, Apr 16, 2020 at 08:24:04PM +0300, Dmitry Osipenko wrote:
> The OF node should be put before returning error in tegra_output_probe(),
> otherwise node's refcount will be leaked.
>
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/tegra/output.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index e36e5e7c2f69..a6a711d54e88 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -102,10 +102,10 @@ int tegra_output_probe(struct tegra_output *output)
> panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
> if (panel) {
> output->panel = of_drm_find_panel(panel);
> + of_node_put(panel);
> +
> if (IS_ERR(output->panel))
> return PTR_ERR(output->panel);
> -
> - of_node_put(panel);
> }
>
> output->edid = of_get_property(output->of_node, "nvidia,edid", );
> @@ -113,13 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
> ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
> if (ddc) {
> output->ddc = of_find_i2c_adapter_by_node(ddc);
> + of_node_put(ddc);
> +
> if (!output->ddc) {
> err = -EPROBE_DEFER;
> - of_node_put(ddc);
> return err;
> }
> -
> - of_node_put(ddc);
> }
>
> output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 05:57:15PM +0200, Enric Balletbo i Serra wrote:
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridge.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index cfa45d6abd74..44ee884cc31c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,7 +182,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_connector conn;
> struct drm_panel *panel;
> - struct drm_bridge *bridge;
> + struct drm_bridge *next_bridge;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -903,8 +903,9 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> dsi->encoder.possible_crtcs = 1;
>
> /* If there's a bridge, attach to it and let it create the connector */
Maybe s/bridge/next bridge/ here ? I expect this comment to go away
though, as there will always be a next bridge when the driver switches
to the DRM panel bridge helper.
Reviewed-by: Laurent Pinchart
> - if (dsi->bridge) {
> - ret = drm_bridge_attach(>encoder, dsi->bridge, NULL, 0);
> + if (dsi->next_bridge) {
> + ret = drm_bridge_attach(>encoder, dsi->next_bridge, NULL,
> + 0);
> if (ret) {
> DRM_ERROR("Failed to attach bridge to drm\n");
> goto err_encoder_cleanup;
> @@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - >panel, >bridge);
> + >panel, >next_bridge);
> if (ret)
> goto err_unregister_host;
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] drm/bridge: ps8640: Get the EDID from eDP control
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 05:57:13PM +0200, Enric Balletbo i Serra wrote:
> The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
> .get_edid callback and set the flag to indicate the core to use it.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2: None
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index d3a53442d449..956b76e0a44d 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge
> *bridge,
> return ret;
> }
>
> +static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
> +struct drm_connector *connector)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +
> + return drm_get_edid(connector,
> + ps_bridge->page[PAGE0_DP_CNTL]->adapter);
This will only work if the DDC signals are connected to the PS8640
(quite obviously). Is that guaranteed, or could some systems connect
them directory to an SoC I2C controller ? In the latter case we would
have to report this in the DT bindings of the PS8640. That's not
blocking for this patch, I am just wondering, as I would have expected
the driver to already expose EDID one way or another if this was
available and used.
Reviewed-by: Laurent Pinchart
> +}
> +
> static const struct drm_bridge_funcs ps8640_bridge_funcs = {
> .attach = ps8640_bridge_attach,
> + .get_edid = ps8640_bridge_get_edid,
> .post_disable = ps8640_post_disable,
> .pre_enable = ps8640_pre_enable,
> };
> @@ -296,6 +306,8 @@ static int ps8640_probe(struct i2c_client *client)
>
> ps_bridge->bridge.funcs = _bridge_funcs;
> ps_bridge->bridge.of_node = dev->of_node;
> + ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
> + ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
>
> ps_bridge->page[PAGE0_DP_CNTL] = client;
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/7] drm/bridge_connector: Set default status connected for eDP connectors
Hi Enric, Thank you for the patch. On Thu, Apr 16, 2020 at 05:57:14PM +0200, Enric Balletbo i Serra wrote: > In an eDP application, HPD is not required and on most bridge chips > useless. If HPD is not used, we need to set initial status as connected, > otherwise the connector created by the drm_bridge_connector API remains > in an unknown state. > > Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart > --- > > Changes in v2: None > > drivers/gpu/drm/drm_bridge_connector.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c > b/drivers/gpu/drm/drm_bridge_connector.c > index c6994fe673f3..a58cbde59c34 100644 > --- a/drivers/gpu/drm/drm_bridge_connector.c > +++ b/drivers/gpu/drm/drm_bridge_connector.c > @@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector > *connector, bool force) > case DRM_MODE_CONNECTOR_DPI: > case DRM_MODE_CONNECTOR_LVDS: > case DRM_MODE_CONNECTOR_DSI: > + case DRM_MODE_CONNECTOR_eDP: > status = connector_status_connected; > break; > default: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix page flip ioctl format check
Hi Ville,
Thank you for the patch.
On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Revert back to comparing fb->format->format instead fb->format for the
> page flip ioctl. This check was originally only here to disallow pixel
> format changes, but when we changed it to do the pointer comparison
> we potentially started to reject some (but definitely not all) modifier
> changes as well. In fact the current behaviour depends on whether the
> driver overrides the format info for a specific format+modifier combo.
> Eg. on i915 this now rejects compression vs. no compression changes but
> does not reject any other tiling changes. That's just inconsistent
> nonsense.
>
> The main reason we have to go back to the old behaviour is to fix page
> flipping with Xorg. At some point Xorg got its atomic rights taken away
> and since then we can't page flip between compressed and non-compressed
> fbs on i915. Currently we get no page flipping for any games pretty much
> since Mesa likes to use compressed buffers. Not sure how compositors are
> working around this (don't use one myself). I guess they must be doing
> something to get non-compressed buffers instead. Either that or
> somehow no one noticed the tearing from the blit fallback.
>
> Looking back at the original discussion on this change we pretty much
> just did it in the name of skipping a few extra pointer dereferences.
> However, I've decided not to revert the whole thing in case someone
> has since started to depend on these changes. None of the other checks
> are relevant for i915 anyways.
Do display controller usually support changing modifiers for page flips
? I understand from the information about that i915 does, but is that
usual ? Could there be drivers that really on this check to reject
modifier changes, and that aren't prepared to handle them if they are
not rejected by the core ? I'm not opposed to this change, but I'd like
to carefully consider the fallout.
> Cc: sta...@vger.kernel.org
> Cc: Laurent Pinchart
> Fixes: dbd4d5761e1f ("drm: Replace 'format->format' comparisons to just
> 'format' comparisons")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d6ad60ab0d38..f2ca5315f23b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1153,7 +1153,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> - if (old_fb->format != fb->format) {
> + if (old_fb->format->format != fb->format->format) {
> DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
> format.\n");
> ret = -EINVAL;
> goto out;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: ps8640: Let panel to set the connector type
Hi Enric, Thank you for the patch. On Thu, Apr 16, 2020 at 06:44:04PM +0200, Enric Balletbo i Serra wrote: > The panel connector type should be set by the panel not the bridge, so > remove the connector_type assignment. > > Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart > --- > > drivers/gpu/drm/bridge/parade-ps8640.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > index 956b76e0a44d..13755d278db6 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -278,8 +278,6 @@ static int ps8640_probe(struct i2c_client *client) > if (!panel) > return -ENODEV; > > - panel->connector_type = DRM_MODE_CONNECTOR_eDP; > - > ps_bridge->panel_bridge = devm_drm_panel_bridge_add(dev, panel); > if (IS_ERR(ps_bridge->panel_bridge)) > return PTR_ERR(ps_bridge->panel_bridge); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix page flip ioctl format check
From: Ville Syrjälä
Revert back to comparing fb->format->format instead fb->format for the
page flip ioctl. This check was originally only here to disallow pixel
format changes, but when we changed it to do the pointer comparison
we potentially started to reject some (but definitely not all) modifier
changes as well. In fact the current behaviour depends on whether the
driver overrides the format info for a specific format+modifier combo.
Eg. on i915 this now rejects compression vs. no compression changes but
does not reject any other tiling changes. That's just inconsistent
nonsense.
The main reason we have to go back to the old behaviour is to fix page
flipping with Xorg. At some point Xorg got its atomic rights taken away
and since then we can't page flip between compressed and non-compressed
fbs on i915. Currently we get no page flipping for any games pretty much
since Mesa likes to use compressed buffers. Not sure how compositors are
working around this (don't use one myself). I guess they must be doing
something to get non-compressed buffers instead. Either that or
somehow no one noticed the tearing from the blit fallback.
Looking back at the original discussion on this change we pretty much
just did it in the name of skipping a few extra pointer dereferences.
However, I've decided not to revert the whole thing in case someone
has since started to depend on these changes. None of the other checks
are relevant for i915 anyways.
Cc: sta...@vger.kernel.org
Cc: Laurent Pinchart
Fixes: dbd4d5761e1f ("drm: Replace 'format->format' comparisons to just
'format' comparisons")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d6ad60ab0d38..f2ca5315f23b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1153,7 +1153,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (ret)
goto out;
- if (old_fb->format != fb->format) {
+ if (old_fb->format->format != fb->format->format) {
DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
format.\n");
ret = -EINVAL;
goto out;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: panel: Set connector type for LP120UP1
Hi Enric,
Thank you for the patch.
On Thu, Apr 16, 2020 at 06:44:03PM +0200, Enric Balletbo i Serra wrote:
> The LP120UP1 is a eDP panel, set the connector type accordingly.
>
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/gpu/drm/panel/panel-simple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3ad828eaefe1..6253635601bb 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2168,6 +2168,7 @@ static const struct panel_desc lg_lp120up1 = {
> .width = 267,
> .height = 183,
> },
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> };
>
> static const struct drm_display_mode lg_lp129qe_mode = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
Hi Rob,
Thank you for the review, I will address all your points in v2,
however I have a one neclarity below.
On Thu, 16 Apr 2020, Rob Herring wrote:
On Thu, Apr 16, 2020 at 7:51 AM Adrian Ratiu
wrote:
This converts the Synopsis MIPI DSI binding documentation to
yaml and should be quite straightforward. I've added a missing
ref clk and also added Mark and Rob as maintainers based on
'get_maintainer.pl' results.
Cc: Rob Herring Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
Suggested-by: Laurent Pinchart
Signed-off-by: Adrian Ratiu
---
.../bindings/display/bridge/dw_mipi_dsi.txt | 32 -
.../display/bridge/snps,dw-mipi-dsi.yaml | 66
+++ 2 files changed, 66 insertions(+), 32
deletions(-) delete mode 100644
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
deleted file mode 100644 index b13adf30b8d3.. ---
a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
+++ /dev/null @@ -1,32 +0,0 @@ -Synopsys DesignWare MIPI DSI
host controller - -
-This document defines device tree properties for the Synopsys
DesignWare MIPI -DSI host controller. It doesn't constitue a
device tree binding specification -by itself but is meant to be
referenced by platform-specific device tree -bindings. - -When
referenced from platform device tree bindings the properties
defined in -this document are defined as follows. The platform
device tree bindings are -responsible for defining whether each
optional property is used or not. - -- reg: Memory mapped base
address and length of the DesignWare MIPI DSI - host
controller registers. (mandatory) - -- clocks: References to
all the clocks specified in the clock-names property - as
specified in [1]. (mandatory) - -- clock-names: - - "pclk" is
the peripheral clock for either AHB and APB. (mandatory) - -
"px_clk" is the pixel clock for the DPI/RGB input. (optional) -
-- resets: References to all the resets specified in the
reset-names property - as specified in [2]. (optional) - --
reset-names: string reset name, must be "apb" if
used. (optional) - -- panel or bridge node: see
[3]. (mandatory) - -[1]
Documentation/devicetree/bindings/clock/clock-bindings.txt -[2]
Documentation/devicetree/bindings/reset/reset.txt -[3]
Documentation/devicetree/bindings/display/mipi-dsi-bus.txt diff
--git
a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
new file mode 100644 index ..0ab4125eee30 ---
/dev/null +++
b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
@@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR
BSD-2-Clause) +%YAML 1.2 +--- +$id:
http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml# +
+title: Synopsys DesignWare MIPI DSI host controller +
+maintainers: + - Rob Herring
No thanks, I don't know anything about this hardware. It should
be the owner for this binding, not who applies patches.
Sorry about that, I just followed what get_maintainer.pl -f
returned.
I'm not sure I understand the owner vs maintainers difference for
the "maintainers" entry. How do I find out who is the owner?
Looking at the git log, this file was touched only once when added
in 88dd1e6f9ad8 ("dt-bindings: display: Add Synopsys DW MIPI DSI
host controller") by Philippe CORNU .
Is the person who added the file automatically owner?
(cc'd Philippe)
+ - Mark Rutland
Check current maintainers. Mark is not one anymore.
Yes, I just noticed he got removed in my latest next-20200416
tree, thanks.
+
+description: |
+ This document defines device tree properties for the Synopsys DesignWare MIPI
+ DSI host controller. It doesn't constitue a device tree binding specification
+ by itself but is meant to be referenced by platform-specific device tree
+ bindings.
+
+ When referenced from platform device tree bindings the properties defined in
+ this document are defined as follows. The platform device tree bindings are
+ responsible for defining whether each property is required or optional.
+
Need to reference ($ref) dsi-controller.yaml here.
+properties:
+ reg:
+description: |
+ Memory mapped base address and length of the DesignWare MIPI DSI host
+ controller registers.
Drop the description. That's every 'reg'. You need to say how many
regions (maxItems: 1?).
+
+ clocks:
+description: |
+ References to all the clocks specified in the clock-names property as
+ specifie
Re: [PATCH v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi, Matthias: Matthias Brugger 於 2020年3月26日 週四 下午11:45寫道： > > > > On 26/03/2020 15:51, CK Hu wrote: > > Hi, Matthias: > > > > On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote: > >> Hi CK, > >> > >> On 26/03/2020 00:05, CK Hu wrote: > >>> Hi, Matthias: > >>> > >>> On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote: > > On 11/03/2020 17:53, Enric Balletbo i Serra wrote: > > Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions > > to > > replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path(). > > Those functions will allow DRM driver and others to control the data > > path routing. > > > > Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: Matthias Brugger > > Reviewed-by: CK Hu > > Acked-by: CK Hu > > This patch does not apply against v5.6-rc1. > Please rebase as this is a quite big patch and it won't be easy to do > that by hand. > >>> > >>> I think this patch depends on [1] which has been acked by me and I have > >>> not picked it. The simple way is that you pick [1] first and then pick > >>> this series. > >>> > >>> [1] > >>> https://patchwork.kernel.org/patch/11406227/ > >>> > >> > >> You would need to provide a stable tag for me that I can merge into my > >> tree. You > >> can also try to merge my for-next [1] which has the newest version from > >> Enric. > >> If you see any merge conflict, then we have to do something about it :) > >> > >> Regards, > >> Matthias > >> > >> [1] > >> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next > >> > > > > You have applied this series, so I would not apply other patches which > > would conflict with this series. After this series land on main stream > > (wish it happen in this merge window), I would rebase other patch on > > main stream. > > > > I haven't (yet) send the pull request. If you want to bring in your patches in > v5.7 as well we can find a solution to that. Shall I provide you with a stable > branch which you can merge? This way you can add all your patches in the pull > request as well and we don't have to wait for v5.8 to get things into > mainline. > > Let me know and I'll provide you with a stable branch. This series is in linux-next but does not in main stream. So would you please provide a stable branch so I could pull this series? Regards, Chun-Kuang. > > Regards, > Matthias > > > Regards, > > CK > > > >>> Regards, > >>> CK > >>> > > Regards, > Matthias > > > --- > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 4:52 PM Jason Gunthorpe wrote: > On Thu, Apr 16, 2020 at 02:38:50PM +0200, Arnd Bergmann wrote: > > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > > wrote: > > > Of course, this is all just talk until someone(tm) posts a patch > > > actually making the change. I've looked at the kconfig tool sources > > > before; not going to make the same mistake again. > > > > Right. OTOH whoever implements it gets to pick the color of the > > bikeshed. ;-) > > I hope someone takes it up, especially now that imply, which > apparently used to do this, doesn't any more :) The old 'imply' was something completely different, it was more of a 'try to select if you can so we can assume it's there, but give up if it can only be a module and we need it to be built-in". Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH trivial 0/6] Fix misspellings of "Analog Devices"
On Thu, 16 Apr 2020 12:30:52 +0200, Geert Uytterhoeven wrote: > Hi all, > > In several files the company also known as ADI is spelled as "Analog > Device". However, according to https://www.analog.com/, the company > name is spelled "Analog Devices". > > Hence this patch series, one per subsystem, fixes these misspellings. > > [...] Applied, thanks! [1/6] dt-bindings: Fix misspellings of "Analog Devices" (not applied) [2/6] dma: Fix misspelling of "Analog Devices" (not applied) [3/6] drm: Fix misspellings of "Analog Devices" (not applied) [4/6] iio: Fix misspellings of "Analog Devices" (not applied) [5/6] ALSA: Fix misspellings of "Analog Devices" (not applied) [6/6] ASoC: Fix misspellings of "Analog Devices" commit: b938b25f49cdb47397b0215b69cdd5251b4b2f8b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/8] drm/meson: add Amlogic Video FBC registers
Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing register. Tested-by: Kevin Hilman Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_registers.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h index 8ea00546cd4e..08631fdfe4b9 100644 --- a/drivers/gpu/drm/meson/meson_registers.h +++ b/drivers/gpu/drm/meson/meson_registers.h @@ -144,10 +144,15 @@ #defineVIU_SW_RESET_OSD1 BIT(0) #define VIU_MISC_CTRL0 0x1a06 #defineVIU_CTRL0_VD1_AFBC_MASK 0x17 +#defineVIU_CTRL0_AFBC_TO_VD1 BIT(20) #define VIU_MISC_CTRL1 0x1a07 #defineMALI_AFBC_MISC GENMASK(15, 8) #define D2D3_INTF_LENGTH 0x1a08 #define D2D3_INTF_CTRL0 0x1a09 +#define VD1_AFBCD0_MISC_CTRL 0x1a0a +#defineVD1_AXI_SEL_AFBC(1 << 12) +#defineAFBC_VD1_SEL(1 << 10) +#define VD2_AFBCD1_MISC_CTRL 0x1a0b #define VIU_OSD1_CTRL_STAT 0x1a10 #defineVIU_OSD1_OSD_BLK_ENABLE BIT(0) #defineVIU_OSD1_OSD_MEM_MODE_LINEARBIT(2) @@ -365,6 +370,23 @@ #define VIU_OSD1_OETF_LUT_ADDR_PORT 0x1add #define VIU_OSD1_OETF_LUT_DATA_PORT 0x1ade #define AFBC_ENABLE 0x1ae0 +#define AFBC_MODE 0x1ae1 +#define AFBC_SIZE_IN 0x1ae2 +#define AFBC_DEC_DEF_COLOR 0x1ae3 +#define AFBC_CONV_CTRL 0x1ae4 +#define AFBC_LBUF_DEPTH 0x1ae5 +#define AFBC_HEAD_BADDR 0x1ae6 +#define AFBC_BODY_BADDR 0x1ae7 +#define AFBC_SIZE_OUT 0x1ae8 +#define AFBC_OUT_YSCOPE 0x1ae9 +#define AFBC_STAT 0x1aea +#define AFBC_VD_CFMT_CTRL 0x1aeb +#define AFBC_VD_CFMT_W 0x1aec +#define AFBC_MIF_HOR_SCOPE 0x1aed +#define AFBC_MIF_VER_SCOPE 0x1aee +#define AFBC_PIXEL_HOR_SCOPE 0x1aef +#define AFBC_PIXEL_VER_SCOPE 0x1af0 +#define AFBC_VD_CFMT_H 0x1af1 /* vpp */ #define VPP_DUMMY_DATA 0x1d00 -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 53 ++-
1 file changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index bbf86e9fc0ca..29b85509dbf8 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,10 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if ((fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_MASK) ==
+ DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER)
+ priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
@@ -675,23 +679,32 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
- /* Default mode is 4k per superblock */
- unsigned long block_size = 4096;
- unsigned long body_size;
-
- /* 8bit mem saving mode is 3072bytes per superblock */
- if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
- block_size = 3072;
-
- body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
- (ALIGN(priv->viu.vd1_height0, 32) / 32) *
- block_size;
-
- priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
- /* Header is after body content */
- priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
- body_size) >> 4;
+ if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+ /*
+* In Scatter mode, the header contains the physical
+* body content layout, thus the body content
+* size isn't needed.
+*/
+ priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+ priv->viu.vd1_afbc_body_addr = 0;
+ } else {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
+ unsigned long body_size;
+
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
+ body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+ (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+ block_size;
+
+ priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+ /* Header is after body content */
+ priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+ body_size) >> 4;
+ }
}
priv->viu.vd1_enabled = true;
@@ -754,7 +767,8 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
return false;
}
- if (layout != DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC) {
+ if (layout != DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC &&
+ layout != DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER) {
DRM_DEBUG_KMS("%llx invalid layout %x\n",
modifier, layout);
return false;
@@ -800,8 +814,11 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
This introduces the Scatter Memory layout, means the header contains IOMMU
references to the compressed frames content to optimize memory access
and layout.
In this mode, only the header memory address is needed, thus the content
memory organization is tied to the current producer execution and cannot
be saved/dumped neither transferrable between Amlogic SoCs supporting this
modifier.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 664dd238574a..ac2d4753eb6d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -843,6 +843,19 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER (2ULL << 0)
+
/* Amlogic FBC Layout Options */
#define DRM_FORMAT_MOD_AMLOGIC_FBC_OPTIONS_MASK(0xf << 8)
@@ -854,7 +867,8 @@ extern "C" {
* memory.
*
* This mode reduces body layout to 3072 bytes per 64x32 superblock with
- * the basic layout.
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.
This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
superblock in default mode.
- a 32 bytes per 128x64 header block
This layout is tranferrable between Amlogic SoCs supporting this modifier.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..a1b163a5641f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -309,6 +309,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
/* add more to the end as needed */
@@ -804,6 +805,44 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defines the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
+
+/* Amlogic FBC Layouts */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_MASK (0xf << 0)
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ * superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
An option exist changing the layout superblock size to save memory when
using 8bit components pixels size.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a1b163a5641f..664dd238574a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -843,6 +843,21 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/* Amlogic FBC Layout Options */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_OPTIONS_MASK(0xf << 8)
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..d6dcfd654e9c 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
VPP_COLOR_MNG_ENABLE,
priv->io_base + _REG(VPP_MISC));
+
+ writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+ priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+ priv->io_base + _REG(VIU_MISC_CTRL0));
}
static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm
*priv)
VD_BLEND_POSTBLD_SRC_VD1 |
VD_BLEND_POSTBLD_PREMULT_EN,
priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+ writel_relaxed(priv->viu.vd1_afbc ?
+ (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+ priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
}
void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
/* Update the VD1 registers */
if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
- switch (priv->viu.vd1_planes) {
- case 3:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_2,
- priv->viu.vd1_addr2,
- priv->viu.vd1_stride2,
- priv->viu.vd1_height2,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 2:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_1,
- priv->viu.vd1_addr1,
- priv->viu.vd1_stride1,
- priv->viu.vd1_height1,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 1:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_0,
- priv->viu.vd1_addr0,
- priv->viu.vd1_stride0,
- priv->viu.vd1_height0,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
+ if (priv->viu.vd1_afbc) {
+ writel_relaxed(priv->viu.vd1_afbc_head_addr,
+ priv->io_base +
+ _REG(AFBC_HEAD_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_body_addr,
+ priv->io_base +
+ _REG(AFBC_BODY_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_en,
+ priv->io_base +
+ _REG(AFBC_ENABLE));
+ writel_relaxed(priv->viu.vd1_afbc_mode,
+ priv->io_base +
+ _REG(AFBC_MODE));
+ writel_relaxed(priv->viu.vd1_afbc_size_in,
+ priv->io_base +
+ _REG(AFBC_SIZE_IN));
+ writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+ priv->io_base +
+ _REG(AFBC_DEC_DEF_COLOR));
+ writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+ priv->io_base +
+ _REG(AFBC_CONV_CTRL));
+ writel_relaxed(priv->viu.vd1_afbc_size_out,
+ priv->io_base +
+
[PATCH v5 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 3127bd1a5d70..bbf86e9fc0ca 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
+ priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -672,12 +675,17 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
unsigned long body_size;
- /* Default mode is 4k per superblock */
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
(ALIGN(priv->viu.vd1_height0, 32) / 32) *
- 4096;
+ block_size;
priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
@@ -735,6 +743,9 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
unsigned int layout = modifier &
DRM_FORMAT_MOD_AMLOGIC_FBC(
DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_MASK);
+ unsigned int options = modifier &
+ DRM_FORMAT_MOD_AMLOGIC_FBC(
+ DRM_FORMAT_MOD_AMLOGIC_FBC_OPTIONS_MASK);
if (format != DRM_FORMAT_YUV420_8BIT &&
format != DRM_FORMAT_YUV420_10BIT) {
@@ -749,6 +760,13 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
return false;
}
+ if (options &&
+ options != DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING) {
+ DRM_DEBUG_KMS("%llx invalid layout %x\n",
+ modifier, layout);
+ return false;
+ }
+
return true;
}
@@ -782,6 +800,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/8] drm/meson: overlay: setup overlay for Amlogic FBC
Setup the Amlogic FBC decoder for the VD1 video overlay plane.
The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.
This adds support for the basic layout, and needs to calculate the content
body size since the header is allocated after.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.h | 16 ++
drivers/gpu/drm/meson/meson_overlay.c | 252 +-
2 files changed, 260 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index 04fdf3826643..da951964e988 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -80,6 +80,7 @@ struct meson_drm {
bool vd1_enabled;
bool vd1_commit;
+ bool vd1_afbc;
unsigned int vd1_planes;
uint32_t vd1_if0_gen_reg;
uint32_t vd1_if0_luma_x0;
@@ -105,6 +106,21 @@ struct meson_drm {
uint32_t vd1_height0;
uint32_t vd1_height1;
uint32_t vd1_height2;
+ uint32_t vd1_afbc_mode;
+ uint32_t vd1_afbc_en;
+ uint32_t vd1_afbc_head_addr;
+ uint32_t vd1_afbc_body_addr;
+ uint32_t vd1_afbc_conv_ctrl;
+ uint32_t vd1_afbc_dec_def_color;
+ uint32_t vd1_afbc_vd_cfmt_ctrl;
+ uint32_t vd1_afbc_vd_cfmt_w;
+ uint32_t vd1_afbc_vd_cfmt_h;
+ uint32_t vd1_afbc_mif_hor_scope;
+ uint32_t vd1_afbc_mif_ver_scope;
+ uint32_t vd1_afbc_size_out;
+ uint32_t vd1_afbc_pixel_hor_scope;
+ uint32_t vd1_afbc_pixel_ver_scope;
+ uint32_t vd1_afbc_size_in;
uint32_t vpp_pic_in_height;
uint32_t vpp_postblend_vd1_h_start_end;
uint32_t vpp_postblend_vd1_v_start_end;
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 2468b0212d52..3127bd1a5d70 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 Amlogic, Inc. All rights reserved.
*/
+#define DEBUG
#include
#include
@@ -76,6 +77,84 @@
#define VD_REGION24_START(value) FIELD_PREP(GENMASK(11, 0), value)
#define VD_REGION13_END(value) FIELD_PREP(GENMASK(27, 16), value)
+/* AFBC_ENABLE */
+#define AFBC_DEC_ENABLEBIT(8)
+#define AFBC_FRM_START BIT(0)
+
+/* AFBC_MODE */
+#define AFBC_HORZ_SKIP_UV(value) FIELD_PREP(GENMASK(1, 0), value)
+#define AFBC_VERT_SKIP_UV(value) FIELD_PREP(GENMASK(3, 2), value)
+#define AFBC_HORZ_SKIP_Y(value)FIELD_PREP(GENMASK(5, 4), value)
+#define AFBC_VERT_SKIP_Y(value)FIELD_PREP(GENMASK(7, 6), value)
+#define AFBC_COMPBITS_YUV(value) FIELD_PREP(GENMASK(13, 8), value)
+#define AFBC_COMPBITS_8BIT 0
+#define AFBC_COMPBITS_10BIT(2 | (2 << 2) | (2 << 4))
+#define AFBC_BURST_LEN(value) FIELD_PREP(GENMASK(15, 14), value)
+#define AFBC_HOLD_LINE_NUM(value) FIELD_PREP(GENMASK(22, 16), value)
+#define AFBC_MIF_URGENT(value) FIELD_PREP(GENMASK(25, 24), value)
+#define AFBC_REV_MODE(value) FIELD_PREP(GENMASK(27, 26), value)
+#define AFBC_BLK_MEM_MODE BIT(28)
+#define AFBC_SCATTER_MODE BIT(29)
+#define AFBC_SOFT_RESETBIT(31)
+
+/* AFBC_SIZE_IN */
+#define AFBC_HSIZE_IN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_IN(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_DEC_DEF_COLOR */
+#define AFBC_DEF_COLOR_Y(value)FIELD_PREP(GENMASK(29, 20),
value)
+#define AFBC_DEF_COLOR_U(value)FIELD_PREP(GENMASK(19, 10),
value)
+#define AFBC_DEF_COLOR_V(value)FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_CONV_CTRL */
+#define AFBC_CONV_LBUF_LEN(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_LBUF_DEPTH */
+#define AFBC_DEC_LBUF_DEPTH(value) FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_LBUF_DEPTH(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_OUT_XSCOPE/AFBC_SIZE_OUT */
+#define AFBC_HSIZE_OUT(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_OUT(value) FIELD_PREP(GENMASK(12, 0), value)
+#define AFBC_OUT_HORZ_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_HORZ_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_OUT_YSCOPE */
+#define AFBC_OUT_VERT_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_VERT_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_CTRL */
+#define AFBC_HORZ_RPT_PIXEL0 BIT(23)
+#define AFBC_HORZ_Y_C_RATIO(value) FIELD_PREP(GENMASK(22, 21), value)
[PATCH v5 0/8] drm/meson: add support for Amlogic Video FBC
Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders. It considerably reduces memory bandwidth while writing and reading frames in memory. The underlying storage is considered to be 3 components, 8bit or 10-bit per component, YCbCr 420, single plane : - DRM_FORMAT_YUV420_8BIT - DRM_FORMAT_YUV420_10BIT This modifier will be notably added to DMA-BUF frames imported from the V4L2 Amlogic VDEC decoder. At least two layout are supported : - Basic: composed of a body and a header - Scatter: the buffer is filled with a IOMMU scatter table referring to the encoder current memory layout. This mode if more efficient in terms of memory allocation but frames are not dumpable and only valid during until the buffer is freed and back in control of the encoder At least two options are supported : - Memory saving: when the pixel bpp is 8b, the size of the superblock can be reduced, thus saving memory. This serie adds the missing register, updated the FBC decoder registers content to be committed by the crtc code. The Amlogic FBC has been tested with compressed content from the Amlogic HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit (Scatter on G12A/SM1, default on GXL). It's expected to work as-is on GXM and G12B SoCs. Changes since v4 at [4]: - added layout and options mask - cosmetic changes in fourcc.h - fixed mod check using the masks - fixed plane apply using the masks Changes since v3 at [3]: - added dropped fourcc patch for scatter - fixed build of last patch Changes since v2 at [2]: - Added "BASIC" layout and moved the SCATTER mode as layout, making BASIC and SCATTER layout exclusives - Moved the Memory Saving at bit 8 for options fields - Split fourcc and overlay patch to introduce basic, mem saving and then scatter in separate patches - Added comment about "transferability" of the buffers Changes since v1 at [1]: - s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h [1] https://patchwork.freedesktop.org/series/73722/#rev1 [2] https://patchwork.freedesktop.org/series/73722/#rev2 [3] https://patchwork.freedesktop.org/series/73722/#rev3 [4] https://patchwork.freedesktop.org/series/73722/#rev4 Neil Armstrong (8): drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression drm/meson: add Amlogic Video FBC registers drm/meson: overlay: setup overlay for Amlogic FBC drm/meson: crtc: handle commit of Amlogic FBC frames drm/fourcc: amlogic: Add modifier definitions for Memory Saving option drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode drm/fourcc: amlogic: Add modifier definitions for the Scatter layout drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout drivers/gpu/drm/meson/meson_crtc.c | 118 +++--- drivers/gpu/drm/meson/meson_drv.h | 16 ++ drivers/gpu/drm/meson/meson_overlay.c | 289 +++- drivers/gpu/drm/meson/meson_registers.h | 22 ++ include/uapi/drm/drm_fourcc.h | 68 ++ 5 files changed, 475 insertions(+), 38 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Applied "ASoC: Fix misspellings of "Analog Devices"" to the asoc tree
The patch ASoC: Fix misspellings of "Analog Devices" has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From b938b25f49cdb47397b0215b69cdd5251b4b2f8b Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 16 Apr 2020 12:30:58 +0200 Subject: [PATCH] ASoC: Fix misspellings of "Analog Devices" According to https://www.analog.com/, the company name is spelled "Analog Devices". Signed-off-by: Geert Uytterhoeven Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20200416103058.15269-7-geert+rene...@glider.be Signed-off-by: Mark Brown --- sound/soc/codecs/ad1980.c | 2 +- sound/soc/codecs/ad73311.c | 2 +- sound/soc/codecs/wm8782.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index c4414c725c1f..43b1337bac37 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -2,7 +2,7 @@ /* * ad1980.c -- ALSA Soc AD1980 codec support * - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Roy Huang * Cliff Cai */ diff --git a/sound/soc/codecs/ad73311.c b/sound/soc/codecs/ad73311.c index 10daf61f0294..b98bf19f594e 100644 --- a/sound/soc/codecs/ad73311.c +++ b/sound/soc/codecs/ad73311.c @@ -2,7 +2,7 @@ /* * ad73311.c -- ALSA Soc AD73311 codec support * - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Cliff Cai */ diff --git a/sound/soc/codecs/wm8782.c b/sound/soc/codecs/wm8782.c index aa5577e364d0..f89855c616eb 100644 --- a/sound/soc/codecs/wm8782.c +++ b/sound/soc/codecs/wm8782.c @@ -7,7 +7,7 @@ * Author: Johannes Stezenbach * * based on ad73311.c - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Cliff Cai */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver
On Thu, Apr 16, 2020 at 08:51:14AM +0200, Daniel Vetter wrote: > On Wed, Apr 15, 2020 at 11:22 PM Arnd Bergmann wrote: > > On Wed, Apr 15, 2020 at 11:12 PM Laurent Pinchart wrote: > > > On Wed, Apr 15, 2020 at 09:07:14PM +0200, Arnd Bergmann wrote: > > > > On Wed, Apr 15, 2020 at 5:18 PM Arnd Bergmann wrote: > > > > > On Wed, Apr 15, 2020 at 4:13 PM Geert Uytterhoeven > > > > > wrote: > > > > > > On Wed, Apr 15, 2020 at 3:47 PM Arnd Bergmann wrote: > > > > > > > On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart > > > > > > > wrote: > > > > > > > > Doesn't "imply" mean it gets selected by default but can be > > > > > > > > manually > > > > > > > > disabled ? > > > > > > > > > > > > > > That may be what it means now (I still don't understand how it's > > > > > > > defined > > > > > > > as of v5.7-rc1), but traditionally it was more like a 'select if > > > > > > > all > > > > > > > dependencies are met'. > > > > > > > > > > > > That's still what it is supposed to mean right now ;-) > > > > > > Except that now it should correctly handle the modular case, too. > > > > > > > > > > Then there is a bug. If I run 'make menuconfig' now on a mainline > > > > > kernel > > > > > and enable CONFIG_DRM_RCAR_DU, I can set > > > > > DRM_RCAR_CMM and DRM_RCAR_LVDS to 'y', 'n' or 'm' regardless > > > > > of whether CONFIG_DRM_RCAR_DU is 'm' or 'y'. The 'implies' > > > > > statement seems to be ignored entirely, except as reverse 'default' > > > > > setting. > > > > > > > > Here is another version that should do what we want and is only > > > > half-ugly. I can send that as a proper patch if it passes my testing > > > > and nobody hates it too much. > > > > > > This may be a stupid question, but doesn't this really call for fixing > > > Kconfig ? This seems to be such a common pattern that requiring > > > constructs similar to the ones below will be a never-ending chase of > > > offenders. > > > > Maybe, I suppose the hardest part here would be to come up with > > an appropriate name for the keyword ;-) > > > > Any suggestions? Would it make sense to fix the imply semantics ? Or are they use cases for the current behaviour of imply ? "recommend" could be another keyword. I think we should try to limit the number of keywords though, as it would otherwise become quite messy. > > This specific issue is fairly rare though, in most cases the dependencies > > are in the right order so a Kconfig symbol 'depends on' a second one > > when the corresponding loadable module uses symbols from that second > > module. The problem here is that the two are mixed up. > > > > The much more common problem is the one where one needs to > > wrong > > > > config FOO > >depends on BAR || !BAR > > > > To ensure the dependency is either met or BAR is disabled, but > > not FOO=y with BAR=m. If you have any suggestions for a keyword > > for that thing, we can clean up hundreds of such instances. > > Some ideas: > > config FOO > can use BAR > maybe BAR > optional BAR Another idea, depends optionally on BAR > We should probably double-check that this is only ever used for when > both FOO and BAR are tri-state, since without that it doesn't make > much sense. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
On Thu, Apr 16, 2020 at 7:51 AM Adrian Ratiu wrote: > > This converts the Synopsis MIPI DSI binding documentation to yaml and > should be quite straightforward. I've added a missing ref clk and also > added Mark and Rob as maintainers based on 'get_maintainer.pl' results. > > Cc: Rob Herring > Cc: Mark Rutland > Cc: devicet...@vger.kernel.org > Suggested-by: Laurent Pinchart > Signed-off-by: Adrian Ratiu > --- > .../bindings/display/bridge/dw_mipi_dsi.txt | 32 - > .../display/bridge/snps,dw-mipi-dsi.yaml | 66 +++ > 2 files changed, 66 insertions(+), 32 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > create mode 100644 > Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > deleted file mode 100644 > index b13adf30b8d3.. > --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > +++ /dev/null > @@ -1,32 +0,0 @@ > -Synopsys DesignWare MIPI DSI host controller > - > - > -This document defines device tree properties for the Synopsys DesignWare MIPI > -DSI host controller. It doesn't constitue a device tree binding specification > -by itself but is meant to be referenced by platform-specific device tree > -bindings. > - > -When referenced from platform device tree bindings the properties defined in > -this document are defined as follows. The platform device tree bindings are > -responsible for defining whether each optional property is used or not. > - > -- reg: Memory mapped base address and length of the DesignWare MIPI DSI > - host controller registers. (mandatory) > - > -- clocks: References to all the clocks specified in the clock-names property > - as specified in [1]. (mandatory) > - > -- clock-names: > - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) > - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) > - > -- resets: References to all the resets specified in the reset-names property > - as specified in [2]. (optional) > - > -- reset-names: string reset name, must be "apb" if used. (optional) > - > -- panel or bridge node: see [3]. (mandatory) > - > -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt > -[2] Documentation/devicetree/bindings/reset/reset.txt > -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt > diff --git > a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > new file mode 100644 > index ..0ab4125eee30 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml > @@ -0,0 +1,66 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Synopsys DesignWare MIPI DSI host controller > + > +maintainers: > + - Rob Herring No thanks, I don't know anything about this hardware. It should be the owner for this binding, not who applies patches. > + - Mark Rutland Check current maintainers. Mark is not one anymore. > + > +description: | > + This document defines device tree properties for the Synopsys DesignWare > MIPI > + DSI host controller. It doesn't constitue a device tree binding > specification > + by itself but is meant to be referenced by platform-specific device tree > + bindings. > + > + When referenced from platform device tree bindings the properties defined > in > + this document are defined as follows. The platform device tree bindings are > + responsible for defining whether each property is required or optional. > + Need to reference ($ref) dsi-controller.yaml here. > +properties: > + reg: > +description: | > + Memory mapped base address and length of the DesignWare MIPI DSI host > + controller registers. Drop the description. That's every 'reg'. You need to say how many regions (maxItems: 1?). > + > + clocks: > +description: | > + References to all the clocks specified in the clock-names property as > + specified in Documentation/devicetree/bindings/clock/clock-bindings.txt Drop > +items: > + - description: Module clock > + - description: DSI bus colck for either AHB and APB typo > + - description: Pixel clock for the DPI/RGB input > +minItems: 2 > +maxItems: 3 You can drop 'maxItems'. It's implied by the length of 'items'. > + > + clock-names: > +items: > + - const: ref > + - const: pclk > + - const: px_clk > +minItems: 2 > +maxItems: 3 > + > + resets: > +description: | > + References to all the resets specified in the reset-names property as >
Re: [PATCH v2 02/36] dt-bindings: display: look for dsi* nodes in dsi-controller
On Thu, Apr 16, 2020 at 6:26 AM Linus Walleij wrote: > > On Wed, Apr 8, 2020 at 9:51 PM Sam Ravnborg wrote: > > > Rob wrote: > > > > Uhhh, it's looking for dsi-controller(@.*)? which is not the common > > case found in dts files. We should fix that to dsi(@.*)?. > > > > See: https://lore.kernel.org/dri-devel/2020031903.GK29911@bogus/ > > > > Fix it. > > > > Signed-off-by: Sam Ravnborg > > Cc: Linus Walleij > > Cc: Rob Herring > > I think I was instructed to use dsi-controller@ at some point but I > suppose it was a misunderstanding. Probably my fault. We've been nice and inconsistent on naming patterns. I always have to double check whether it is 'gpio-controller@' or 'gpio@'... The answer is always whatever has the most hits in dts files. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Thu, Apr 16, 2020 at 7:44 AM Sam Ravnborg wrote: > > Hi Rob. > > On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > > Fix various inconsistencies in schema indentation. Most of these are > > list indentation which should be 2 spaces more than the start of the > > enclosing keyword. This doesn't matter functionally, but affects running > > scripts which do transforms on the schema files. > > Are there any plans to improve the tooling so we get warnigns for this? I've been experimenting with yamllint some. I haven't figured out how to best integrate it in. Probably need to start with something minimal and warning free for the tree and then add to it. There's also yaml-format in the dtschema repo which just reads in and writes out a yaml file using ruamel round trip yaml parser. That's what I used here. > Otherwise I am afraid we will see a lot of patches that gets this wrong. > > As a follow-up patch it would be good if example-schema.yaml > could gain some comments about the correct indentions. Sure, I can do that. > > Some comments in the following. > > > diff --git a/Documentation/devicetree/bindings/arm/altera.yaml > > b/Documentation/devicetree/bindings/arm/altera.yaml > > index 49e0362ddc11..b388c5aa7984 100644 > > --- a/Documentation/devicetree/bindings/arm/altera.yaml > > +++ b/Documentation/devicetree/bindings/arm/altera.yaml > > @@ -13,8 +13,8 @@ properties: > >compatible: > > items: > >- enum: > > -- altr,socfpga-cyclone5 > > -- altr,socfpga-arria5 > > -- altr,socfpga-arria10 > > + - altr,socfpga-cyclone5 > > + - altr,socfpga-arria5 > > + - altr,socfpga-arria10 > >- const: altr,socfpga > > So here "- enum" do not need the extra indent. > Is it because this is not a list? Right. Indentation is 2 more spaces than the parent keyword ignoring any hyphen in the parent. > > diff --git > > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > > > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > index 66213bd95e6e..6cc74523ebfd 100644 > > --- > > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > +++ > > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > @@ -25,7 +25,7 @@ select: > > > > properties: > >compatible: > > - items: > > +items: > >- const: amlogic,meson-gx-ao-secure > >- const: syscon > > This is something I had expected the tooling to notice. > I had expected the two "- const" to be indented with 4 spaces, not two. > So there is something I do not understand. As above, correct indenting is 2 spaces from the parent not counting any '-' in the parent, but the '-' counts for indenting the children. Arguably, this style is inconsistent that sometimes the '-' counts and sometimes it doesn't. However, I think this style is better because it distinguishes lists vs. dicts more clearly. It's easy to miss the '-' when the indentation is the same: - foo: - bar - baz - foo: bar baz Or worse: - foo: - bar baz Both styles are valid. It's just a tabs vs. spaces debate, and I just picked one. > > diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > > b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > > index 07f39d3eee7e..f7f024910e71 100644 > > --- a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > > +++ b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > > @@ -17,9 +17,8 @@ properties: > >- nxp,lpc3230 > >- nxp,lpc3240 > >- items: > > -- enum: > > -- ea,ea3250 > > -- phytec,phy3250 > > -- const: nxp,lpc3250 > > - > > + - enum: > > + - ea,ea3250 > > + - phytec,phy3250 > > + - const: nxp,lpc3250 > > ... > > And here "- enum" receive extra indent. > > I trust you know what you are doing - but I do not get it. > > Some pointers or examples for the correct indention would be great. With this patch, the tree is all correct examples. :) > I cannot review this patch as long as I do not know the rules. > > My request to update example-schema.yaml was one way to teach me. > (Some people will say that is difficult/impossible to teach me, > but thats another story:-) ). > > Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/modes: Indicate CEA-861 CE modes to user-space
On Tue, 2020-04-14 at 14:41 +0200, Daniel Vetter wrote:
> On Mon, Apr 13, 2020 at 11:40:22PM +0200, Yussuf Khalil wrote:
> > Add a new flag to mark modes that are considered a CE mode
> > according to the
> > CEA-861 specification. Modes without this flag are implicitly
> > considered to
> > be IT modes.
> >
> > User-space applications may use this flag to determine possible
> > implications of using a CE mode (e.g., limited RGB range).
> >
> > There is no use for this flag inside the kernel, so we set it only
> > when
> > communicating a mode to user-space.
> >
> > Signed-off-by: Yussuf Khalil
>
> Do we have userspace for this?
>
> If we go with the existing quant range property you don't need new
> userspace for the property itself. But this flag here is new uapi, so
> needs userspace per
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>
> Also since this standardizes kms uapi, we need testcases per
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-requirements-for-userspace-api
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/drm_modes.c | 14 ++
> > include/uapi/drm/drm_mode.h | 2 ++
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c
> > b/drivers/gpu/drm/drm_modes.c
> > index d4d64518e11b..0d8a032f437d 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1973,6 +1973,14 @@ void drm_mode_convert_to_umode(struct
> > drm_mode_modeinfo *out,
> > break;
> > }
> >
> > + if (drm_match_cea_mode(in) > 1) {
> > + /*
> > +* All modes in CTA-861-G Table 1 are CE modes, except
> > 640x480p
> > +* (VIC 1).
> > +*/
> > + out->flags |= DRM_MODE_FLAG_CEA_861_CE_MODE;
> > + }
> > +
> > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> > }
> > @@ -2045,6 +2053,12 @@ int drm_mode_convert_umode(struct drm_device
> > *dev,
> > return -EINVAL;
> > }
> >
> > + /*
> > +* The CEA-861 CE mode flag is purely informational and
> > intended for
> > +* userspace only.
> > +*/
> > + out->flags &= ~DRM_MODE_FLAG_CEA_861_CE_MODE;
> > +
> > out->status = drm_mode_validate_driver(dev, out);
> > if (out->status != MODE_OK)
> > return -EINVAL;
> > diff --git a/include/uapi/drm/drm_mode.h
> > b/include/uapi/drm/drm_mode.h
> > index 735c8cfdaaa1..5e78b350b2e2 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -124,6 +124,8 @@ extern "C" {
> > #define DRM_MODE_FLAG_PIC_AR_256_135 \
> > (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> >
> > +#define DRM_MODE_FLAG_CEA_861_CE_MODE (1<<23)
> > +
> > #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> > DRM_MODE_FLAG_NHSYNC | \
> > DRM_MODE_FLAG_PVSYNC | \
> > --
> > 2.26.0
> >
Sorry, I wasn't aware DRM had these additional requirements. I do have a user-
space implementation in mutter and gnome-control-center that makes use of the
new property and this flag on my local machine. I'll try to propose the branch
upstream before sending in the next revision of this patchset.
Do I understand it correctly that this will require test cases for both the
property itself and the new flag? I'll write a patch for IGT then.
Regards
Yussuf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: Add per-pixel alpha support for the PX30 VOP
Compared to its predecessors, the PX30 VOP has a different register layout
for enabling per-pixel alpha. Instead of src_alpha_ctl and dst_alpha_ctl,
there is a single alpha control register. This register takes some fields
from src_alpha_ctl, but with a different layout.
Add support for the required fields to the PX30 VOP window descriptions,
which makes per-pixel-alpha formats behave correctly.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 3 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 9 +
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d04b3492bdac..ac1b1923c4bc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -906,6 +906,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
SRC_ALPHA_CAL_M0(ALPHA_NO_SATURATION) |
SRC_FACTOR_M0(ALPHA_ONE);
VOP_WIN_SET(vop, win, src_alpha_ctl, val);
+
+ VOP_WIN_SET(vop, win, alpha_pre_mul, ALPHA_SRC_PRE_MUL);
+ VOP_WIN_SET(vop, win, alpha_mode, ALPHA_PER_PIX);
+ VOP_WIN_SET(vop, win, alpha_en, 1);
} else {
VOP_WIN_SET(vop, win, src_alpha_ctl, SRC_ALPHA_EN(0));
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 0b3d18c457b2..562b127d120b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -151,6 +151,9 @@ struct vop_win_phy {
struct vop_reg dst_alpha_ctl;
struct vop_reg src_alpha_ctl;
+ struct vop_reg alpha_pre_mul;
+ struct vop_reg alpha_mode;
+ struct vop_reg alpha_en;
struct vop_reg channel;
};
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7a9d979c8d5d..67bb2625db68 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -244,6 +244,9 @@ static const struct vop_win_phy px30_win0_data = {
.uv_mst = VOP_REG(PX30_WIN0_CBR_MST0, 0x, 0),
.yrgb_vir = VOP_REG(PX30_WIN0_VIR, 0x1fff, 0),
.uv_vir = VOP_REG(PX30_WIN0_VIR, 0x1fff, 16),
+ .alpha_pre_mul = VOP_REG(PX30_WIN0_ALPHA_CTRL, 0x1, 2),
+ .alpha_mode = VOP_REG(PX30_WIN0_ALPHA_CTRL, 0x1, 1),
+ .alpha_en = VOP_REG(PX30_WIN0_ALPHA_CTRL, 0x1, 0),
};
static const struct vop_win_phy px30_win1_data = {
@@ -256,6 +259,9 @@ static const struct vop_win_phy px30_win1_data = {
.dsp_st = VOP_REG(PX30_WIN1_DSP_ST, 0x, 0),
.yrgb_mst = VOP_REG(PX30_WIN1_MST, 0x, 0),
.yrgb_vir = VOP_REG(PX30_WIN1_VIR, 0x1fff, 0),
+ .alpha_pre_mul = VOP_REG(PX30_WIN1_ALPHA_CTRL, 0x1, 2),
+ .alpha_mode = VOP_REG(PX30_WIN1_ALPHA_CTRL, 0x1, 1),
+ .alpha_en = VOP_REG(PX30_WIN1_ALPHA_CTRL, 0x1, 0),
};
static const struct vop_win_phy px30_win2_data = {
@@ -269,6 +275,9 @@ static const struct vop_win_phy px30_win2_data = {
.dsp_st = VOP_REG(PX30_WIN2_DSP_ST0, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(PX30_WIN2_MST0, 0x, 0),
.yrgb_vir = VOP_REG(PX30_WIN2_VIR0_1, 0x1fff, 0),
+ .alpha_pre_mul = VOP_REG(PX30_WIN2_ALPHA_CTRL, 0x1, 2),
+ .alpha_mode = VOP_REG(PX30_WIN2_ALPHA_CTRL, 0x1, 1),
+ .alpha_en = VOP_REG(PX30_WIN2_ALPHA_CTRL, 0x1, 0),
};
static const struct vop_win_data px30_vop_big_win_data[] = {
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Multiple regulators for one device [was drm/panfrost: add devfreq regulator support]
On Thu, Apr 16, 2020 at 02:42:13PM +0100, Steven Price wrote: > On 14/04/2020 20:16, Clément Péron wrote: > > That's can be reworked and Panfrost can only probe regulator if there > > is no opp-table. > This is what I was thinking about looking at. But it may make sense instead > to extend the regulator API to allow multiple regualtor_get() calls for a > single device. I haven't had time to dig into how difficult this would be. To repeat what I said before we don't actively stop this, it's just not something that seems particularly tasteful and the warning does find actual errors. I definitely don't think it's a good idea to extend the API for this. > Ideally calling regulator_get a second time for the same device would simply > return the same struct regulator object (with a reference count increment). One of the goals with the distinct struct regulator is to make sure that we track all the user's activity together - if we mix multiple users in there it becomes harder to tell if something is going wrong. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property
On Wed, 2020-04-15 at 13:13 +0200, Daniel Vetter wrote: > On Wed, Apr 15, 2020 at 10:33:25AM +0300, Jani Nikula wrote: > > On Tue, 14 Apr 2020, Yussuf Khalil wrote: > > > On Tue, 2020-04-14 at 14:34 +0200, Daniel Vetter wrote: > > > > On Tue, Apr 14, 2020 at 02:21:06PM +0300, Jani Nikula wrote: > > > > > On Tue, 14 Apr 2020, Jani Nikula > > > > > > > > > > wrote: > > > > > > On Mon, 13 Apr 2020, Simon Ser wrote: > > > > > > > On Monday, April 13, 2020 11:40 PM, Yussuf Khalil < > > > > > > > d...@pp3345.net> wrote: > > > > > > > > > > > > > > > DRM now has a globally available "RGB quantization > > > > > > > > range" > > > > > > > > connector > > > > > > > > property. i915's "Broadcast RGB" that fulfils the same > > > > > > > > purpose is now > > > > > > > > considered deprecated, so drop it in favor of the DRM > > > > > > > > property. > > > > > > > > > > > > > > For a UAPI point-of-view, I'm not sure this is fine. Some > > > > > > > user- > > > > > > > space > > > > > > > might depend on this property, dropping it would break > > > > > > > such > > > > > > > user-space. > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > Can we make this property deprecated but still keep it > > > > > > > for > > > > > > > backwards > > > > > > > compatibility? > > > > > > > > > > > > Would be nice to make the i915 specific property an "alias" > > > > > > for > > > > > > the new > > > > > > property, however I'm not sure how you'd make that happen. > > > > > > Otherwise > > > > > > juggling between the two properties is going to be a > > > > > > nightmare. > > > > > > > > > > Ah, the obvious easy choice is to use the property and enum > > > > > names > > > > > already being used by i915 and gma500, and you have no > > > > > problem. > > > > > Perhaps > > > > > they're not the names you'd like, but then looking at the > > > > > total > > > > > lack of > > > > > consistency across property naming makes them fit right in. > > > > > ;) > > > > > > > > Yeah if we don't have contradictory usage across drivers when > > > > modernizing > > > > these properties, then let's just stick with the names already > > > > there. > > > > It's > > > > not pretty, but works better since more userspace/internet > > > > howtos > > > > know how > > > > to use this stuff. > > > > -Daniel > > > > > > Note that i915's "Broadcast RGB" isn't the same as gma500's: i915 > > > has an > > > "Automatic" option, whereas gma500 does not. > > > > Adding "Automatic" option that just defaults to "Full" in gma500 > > does > > not break existing userspace, but allows for extending it to do > > more > > clever things later. > > gma500 could keep it's own property, without the "Automatic" value. > We've > done tricks like this for other properties too. > > > > Also, radeon has a property called > > > "output_csc" that fulfills a similar purpose. Looking at the > > > code, though, it > > > seems that radeon does not adhere to the standard correctly (or I > > > am missing > > > something). > > > > > > An alternative would be to leave the existing driver-specific > > > properties and > > > change them to be pseudo-aliases for the "RGB quantization range" > > > property. > > > This can be done by letting the drivers read from and write to > > > the new property > > > when user-space tries to read or modify the driver's property. > > > This way we could > > > retain full backwards compatibility for all drivers equally. > > > > > > What do you think? > > > > I'm obviously biased and predisposed to avoid adding extra > > complexity to > > i915 when it's not necessary. We'd have *two* connector properties > > for > > the same thing until the end of time, even if one is an alias for > > the > > other. > > Yeah just pick one, and implement the others as aliases. Drivers can > do > the aliases in their atomic_get/set_property functions pretty easily, > atomic properties aren't stored anywhere else than decoded (which was > done > partially to make stuff like this work). > > Coming up a new property name just so that everyone suffers equally > feels > silly. > -Daniel Okay, I understand your point. Leaving gma500 without a proper implementation of the "Automatic" value isn't an option though as that would break the whole purpose of this patchset: having a property that works precisely the same way across all drivers. I'll build a patch that implements standards-compliant behavior for gma500 then, so that it can use the same property as the others. Regards Yussuf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Thu, Apr 16, 2020 at 1:52 AM Joe Perches wrote: > > On Wed, 2020-04-15 at 19:55 -0500, Rob Herring wrote: > > json-schema versions draft7 and earlier have a weird behavior in that > > any keywords combined with a '$ref' are ignored (silently). The correct > > form was to put a '$ref' under an 'allOf'. This behavior is now changed > > in the 2019-09 json-schema spec and '$ref' can be mixed with other > > keywords. The json-schema library doesn't yet support this, but the > > tooling now does a fixup for this and either way works. > > > > This has been a constant source of review comments, so let's change this > > treewide so everyone copies the simpler syntax. > > This is a large change. > > Was this done manually or by some script? Scripted with python ruamel yaml, but then I had to filter out all the re-formatting (hence the first patch to cut down some of that). > If it was done manually, how likely is it there are defects > in the conversion? Either way, the schemas still have to pass the meta-schema checks. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/5] drm/amdgpu: utilize subconnector property for DP through atombios
On Wed, Apr 15, 2020 at 6:05 AM Jani Nikula wrote:
>
>
> Alex, Harry, Christian, can you please eyeball this series and see if it
> makes sense for you?
>
Patches 4, 5 are:
Acked-by: Alex Deucher
Feel free to take them through whichever tree you want.
Alex
> Thanks,
> Jani.
>
>
> On Tue, 07 Apr 2020, Jeevan B wrote:
> > From: Oleg Vasilev
> >
> > Since DP-specific information is stored in driver's structures, every
> > driver needs to implement subconnector property by itself.
> >
> > v2: rebase
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: David (ChunMing) Zhou
> > Cc: amd-...@lists.freedesktop.org
> > Signed-off-by: Jeevan B
> > Signed-off-by: Oleg Vasilev
> > Reviewed-by: Emil Velikov
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-6-oleg.vasi...@intel.com
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 ++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
> > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 18 +-
> > 3 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > index f355d9a..71aade0 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> > @@ -26,6 +26,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "amdgpu.h"
> > @@ -1405,6 +1406,10 @@ amdgpu_connector_dp_detect(struct drm_connector
> > *connector, bool force)
> > pm_runtime_put_autosuspend(connector->dev->dev);
> > }
> >
> > + drm_dp_set_subconnector_property(_connector->base,
> > + ret,
> > + amdgpu_dig_connector->dpcd,
> > +
> > amdgpu_dig_connector->downstream_ports);
> > return ret;
> > }
> >
> > @@ -1951,6 +1956,11 @@ amdgpu_connector_add(struct amdgpu_device *adev,
> > if (has_aux)
> > amdgpu_atombios_dp_aux_init(amdgpu_connector);
> >
> > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > + connector_type == DRM_MODE_CONNECTOR_eDP) {
> > +
> > drm_mode_add_dp_subconnector_property(_connector->base);
> > + }
> > +
> > return;
> >
> > failed:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > index 37ba07e..04a430e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > @@ -469,6 +469,7 @@ struct amdgpu_encoder {
> > struct amdgpu_connector_atom_dig {
> > /* displayport */
> > u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > u8 dp_sink_type;
> > int dp_clock;
> > int dp_lane_count;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > index 9b74cfd..900b272 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> > @@ -328,6 +328,22 @@ static void amdgpu_atombios_dp_probe_oui(struct
> > amdgpu_connector *amdgpu_connect
> > buf[0], buf[1], buf[2]);
> > }
> >
> > +static void amdgpu_atombios_dp_ds_ports(struct amdgpu_connector
> > *amdgpu_connector)
> > +{
> > + struct amdgpu_connector_atom_dig *dig_connector =
> > amdgpu_connector->con_priv;
> > + int ret;
> > +
> > + if (dig_connector->dpcd[DP_DPCD_REV] > 0x10) {
> > + ret = drm_dp_dpcd_read(_connector->ddc_bus->aux,
> > +DP_DOWNSTREAM_PORT_0,
> > +dig_connector->downstream_ports,
> > +DP_MAX_DOWNSTREAM_PORTS);
> > + if (ret)
> > + memset(dig_connector->downstream_ports, 0,
> > +DP_MAX_DOWNSTREAM_PORTS);
> > + }
> > +}
> > +
> > int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector *amdgpu_connector)
> > {
> > struct amdgpu_connector_atom_dig *dig_connector =
> > amdgpu_connector->con_priv;
> > @@ -343,7 +359,7 @@ int amdgpu_atombios_dp_get_dpcd(struct amdgpu_connector
> > *amdgpu_connector)
> > dig_connector->dpcd);
> >
> > amdgpu_atombios_dp_probe_oui(amdgpu_connector);
> > -
> > + amdgpu_atombios_dp_ds_ports(amdgpu_connector);
> > return 0;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panfrost: add devfreq regulator support
On Tue, Apr 14, 2020 at 09:16:39PM +0200, Clément Péron wrote: > But if multiple regulator is not an issue and as each request is logic. > The first in device_init assure to enable the regulator and the second > in OPP assure the voltage level. > Maybe we can just fix this warning? Well, if you have a tasteful way of doing it I guess. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Multiple regulators for one device [was drm/panfrost: add devfreq regulator support]
On 14/04/2020 20:16, Clément Péron wrote: Hi Mark, On Tue, 14 Apr 2020 at 20:55, Mark Brown wrote: On Tue, Apr 14, 2020 at 08:20:23PM +0200, Clément Péron wrote: Hi Liam and Mark, You might want to flag stuff like this in the subject line, I very nearly deleted this without opening it since most of the email I get about panfrost appears to be coming from me having sent patches rather than being relevant. Ok will do next time, We are having an issue with Panfrost driver registering two times the same regulator and giving an error when trying to create the debugfs folder. Could you clarify if it is allowed for a device to register two times the same regulator? I check Documentation/power/regulator/regulator.rst but this point is not specified. We don't actively prevent it and I can't think what other than debugfs might run into problems (and that's just a warning) but it does seem like a weird thing to want to do and like it's pointing to some confusion in your code with two different parts of the device controlling the same supply independently. What's the use case here? Panfrost first probe clock, reset and regulator in device_init: https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/gpu/drm/panfrost/panfrost_drv.c#L602 Then it probe for optional devfreq, devfreq will get opp tables and also get regulator again. https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/gpu/drm/panfrost/panfrost_drv.c#L609 That's can be reworked and Panfrost can only probe regulator if there is no opp-table. This is what I was thinking about looking at. But it may make sense instead to extend the regulator API to allow multiple regualtor_get() calls for a single device. I haven't had time to dig into how difficult this would be. But if multiple regulator is not an issue and as each request is logic. The first in device_init assure to enable the regulator and the second in OPP assure the voltage level. Maybe we can just fix this warning? From what I can see in the code, just silencing the warning would lead to 'odd' behaviour with debugfs. The first struct regulator Panfrost acquires is the one that is used purely for turning the GPU on (no voltage scaling). The second struct regulator is the one which is obtained by the OPP framework. However the debugfs entries point into the actual struct regulator, so it would be far more logical/useful if those were pointing into the second struct regulator. Ideally calling regulator_get a second time for the same device would simply return the same struct regulator object (with a reference count increment). Perhaps a better approach would be for Panfrost to hand over the struct regulator objects it has already got to the OPP framework. I.e. open code dev_pm_opp_set_regulators(), but instead of calling regulator_get_optional() simply populate the regulators we already have? The other benefit of that is it would provide a clear hand-over of responsibility between Panfrost handling it's own regulators and the OPP framework picking up the work. The disadvantage is that Panfrost would have to track whether the regulators have been handed over or not. Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: dw_mipi_dsi.txt: convert to yaml
This converts the Synopsis MIPI DSI binding documentation to yaml and should be quite straightforward. I've added a missing ref clk and also added Mark and Rob as maintainers based on 'get_maintainer.pl' results. Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Suggested-by: Laurent Pinchart Signed-off-by: Adrian Ratiu --- .../bindings/display/bridge/dw_mipi_dsi.txt | 32 - .../display/bridge/snps,dw-mipi-dsi.yaml | 66 +++ 2 files changed, 66 insertions(+), 32 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt deleted file mode 100644 index b13adf30b8d3.. --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt +++ /dev/null @@ -1,32 +0,0 @@ -Synopsys DesignWare MIPI DSI host controller - - -This document defines device tree properties for the Synopsys DesignWare MIPI -DSI host controller. It doesn't constitue a device tree binding specification -by itself but is meant to be referenced by platform-specific device tree -bindings. - -When referenced from platform device tree bindings the properties defined in -this document are defined as follows. The platform device tree bindings are -responsible for defining whether each optional property is used or not. - -- reg: Memory mapped base address and length of the DesignWare MIPI DSI - host controller registers. (mandatory) - -- clocks: References to all the clocks specified in the clock-names property - as specified in [1]. (mandatory) - -- clock-names: - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) - -- resets: References to all the resets specified in the reset-names property - as specified in [2]. (optional) - -- reset-names: string reset name, must be "apb" if used. (optional) - -- panel or bridge node: see [3]. (mandatory) - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/reset/reset.txt -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml new file mode 100644 index ..0ab4125eee30 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare MIPI DSI host controller + +maintainers: + - Rob Herring + - Mark Rutland + +description: | + This document defines device tree properties for the Synopsys DesignWare MIPI + DSI host controller. It doesn't constitue a device tree binding specification + by itself but is meant to be referenced by platform-specific device tree + bindings. + + When referenced from platform device tree bindings the properties defined in + this document are defined as follows. The platform device tree bindings are + responsible for defining whether each property is required or optional. + +properties: + reg: +description: | + Memory mapped base address and length of the DesignWare MIPI DSI host + controller registers. + + clocks: +description: | + References to all the clocks specified in the clock-names property as + specified in Documentation/devicetree/bindings/clock/clock-bindings.txt +items: + - description: Module clock + - description: DSI bus colck for either AHB and APB + - description: Pixel clock for the DPI/RGB input +minItems: 2 +maxItems: 3 + + clock-names: +items: + - const: ref + - const: pclk + - const: px_clk +minItems: 2 +maxItems: 3 + + resets: +description: | + References to all the resets specified in the reset-names property as + specified in Documentation/devicetree/bindings/reset/reset.txt + + reset-names: +const: apb + +patternProperties: + "^panel@[0-3]$": +type: object +description: | + A node containing the panel or bridge description as documented in + Documentation/devicetree/bindings/display/mipi-dsi-bus.txt + +required: + - reg + - clocks + - clock-names -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
Hi Rob. On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. Are there any plans to improve the tooling so we get warnigns for this? Otherwise I am afraid we will see a lot of patches that gets this wrong. As a follow-up patch it would be good if example-schema.yaml could gain some comments about the correct indentions. Some comments in the following. > diff --git a/Documentation/devicetree/bindings/arm/altera.yaml > b/Documentation/devicetree/bindings/arm/altera.yaml > index 49e0362ddc11..b388c5aa7984 100644 > --- a/Documentation/devicetree/bindings/arm/altera.yaml > +++ b/Documentation/devicetree/bindings/arm/altera.yaml > @@ -13,8 +13,8 @@ properties: >compatible: > items: >- enum: > -- altr,socfpga-cyclone5 > -- altr,socfpga-arria5 > -- altr,socfpga-arria10 > + - altr,socfpga-cyclone5 > + - altr,socfpga-arria5 > + - altr,socfpga-arria10 >- const: altr,socfpga So here "- enum" do not need the extra indent. Is it because this is not a list? > ... > diff --git > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > index 66213bd95e6e..6cc74523ebfd 100644 > --- > a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > +++ > b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml > @@ -25,7 +25,7 @@ select: > > properties: >compatible: > - items: > +items: >- const: amlogic,meson-gx-ao-secure >- const: syscon This is something I had expected the tooling to notice. I had expected the two "- const" to be indented with 4 spaces, not two. So there is something I do not understand. > diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > index 07f39d3eee7e..f7f024910e71 100644 > --- a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > +++ b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml > @@ -17,9 +17,8 @@ properties: >- nxp,lpc3230 >- nxp,lpc3240 >- items: > -- enum: > -- ea,ea3250 > -- phytec,phy3250 > -- const: nxp,lpc3250 > - > + - enum: > + - ea,ea3250 > + - phytec,phy3250 > + - const: nxp,lpc3250 > ... And here "- enum" receive extra indent. I trust you know what you are doing - but I do not get it. Some pointers or examples for the correct indention would be great. I cannot review this patch as long as I do not know the rules. My request to update example-schema.yaml was one way to teach me. (Some people will say that is difficult/impossible to teach me, but thats another story:-) ). Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/phy-compliance
Quoting Jani Nikula (2020-04-15 10:48:15) > On Wed, 15 Apr 2020, Daniel Vetter wrote: > > On Wed, Apr 15, 2020 at 8:40 AM Jani Nikula > > wrote: > >> > >> On Wed, 08 Apr 2020, Maarten Lankhorst > >> wrote: > >> > Hey, > >> > > >> > Here's a pull request to pull in the DP PHY Compliance series. > >> > It's based on top of drm/drm-next, and contains all patches for core, > >> > amd and i915. :) > >> > >> Ping, I don't see this merged in any tree yet. > > > > Generally topic pull requests get pulled into all relevant trees, > > which would be drm-misc, drm-intel and drm-amd here. All of the > > optional ofc if you do instead maintainer-acks for merging through > > another tree. > > > > Since I wasn't involved in this no idea who requested the topic tree > > instead of acks, and the pull isn't addressed to specific people who > > should pull it in (I generally add that to avoid confusion like this > > here), but this aint something that drm.git needs to pull. Just stuff > > it into one of the trees as usual. Also just noticed that amd > > maintainers arent even cc'ed, adding Alex. You guys pls figure this > > out :-) > > It seemed like drm-misc and drm-intel would be out-of-sync for too long > before we'd get all of them eventually (back)merged together, so I > leaned towards the topic branch. Of course, the point starts to be moot > if it has already taken more than a week to merge this anywhere... > > And I'm pinging about merging the topic pull to drm-misc and drm-intel; > I'm currently not covering drm-intel. Pulled to drm-intel-next-queued now. Regards, Joonas > > BR, > Jani. > > > > > > -Daniel > > > >> > >> BR, > >> Jani. > >> > >> > >> > > >> > Cheers, > >> > Maarten > >> > > >> > topic/phy-compliance-2020-04-08: > >> > Topic pull request for topic/phy-compliance: > >> > - Standardize DP_PHY_TEST_PATTERN name. > >> > - Add support for setting/getting test pattern from sink. > >> > - Implement DP PHY compliance to i915. > >> > The following changes since commit > >> > 12ab316ced2c5f32ced0e6300a054db644b5444a: > >> > > >> > Merge tag 'amd-drm-next-5.7-2020-04-01' of > >> > git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 > >> > 09:34:27 +1000) > >> > > >> > are available in the Git repository at: > >> > > >> > git://anongit.freedesktop.org/drm/drm-misc > >> > tags/topic/phy-compliance-2020-04-08 > >> > > >> > for you to fetch changes up to 8cdf727119289db3a98835662eb28e1c5ad835f1: > >> > > >> > drm/i915/dp: Program vswing, pre-emphasis, test-pattern (2020-04-08 > >> > 14:41:09 +0200) > >> > > >> > > >> > Topic pull request for topic/phy-compliance: > >> > - Standardize DP_PHY_TEST_PATTERN name. > >> > - Add support for setting/getting test pattern from sink. > >> > - Implement DP PHY compliance to i915. > >> > > >> > > >> > Animesh Manna (7): > >> > drm/amd/display: Align macro name as per DP spec > >> > drm/dp: get/set phy compliance pattern > >> > drm/i915/dp: Made intel_dp_adjust_train() non-static > >> > drm/i915/dp: Preparation for DP phy compliance auto test > >> > drm/i915/dp: Add debugfs entry for DP phy compliance > >> > drm/i915/dp: Register definition for DP compliance register > >> > drm/i915/dp: Program vswing, pre-emphasis, test-pattern > >> > > >> > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > >> > drivers/gpu/drm/drm_dp_helper.c| 94 +++ > >> > .../gpu/drm/i915/display/intel_display_debugfs.c | 12 +- > >> > drivers/gpu/drm/i915/display/intel_display_types.h | 1 + > >> > drivers/gpu/drm/i915/display/intel_dp.c| 171 > >> > + > >> > drivers/gpu/drm/i915/display/intel_dp.h| 1 + > >> > .../gpu/drm/i915/display/intel_dp_link_training.c | 9 +- > >> > .../gpu/drm/i915/display/intel_dp_link_training.h | 4 + > >> > drivers/gpu/drm/i915/i915_reg.h| 18 +++ > >> > include/drm/drm_dp_helper.h| 33 +++- > >> > 10 files changed, 337 insertions(+), 8 deletions(-) > >> > >> -- > >> Jani Nikula, Intel Open Source Graphics Center > > -- > Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula wrote: > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed wrote: > >> BTW how about adding a new Kconfig option to hide the details of > >> ( BAR || !BAR) ? as Jason already explained and suggested, this will > >> make it easier for the users and developers to understand the actual > >> meaning behind this tristate weird condition. > >> > >> e.g have a new keyword: > >> reach VXLAN > >> which will be equivalent to: > >> depends on VXLAN && !VXLAN > > > > I'd love to see that, but I'm not sure what keyword is best. For your > > suggestion of "reach", that would probably do the job, but I'm not > > sure if this ends up being more or less confusing than what we have > > today. > > Ah, perfect bikeshedding topic! > > Perhaps "uses"? If the dependency is enabled it gets used as a > dependency. That seems to be the best naming suggestion so far > Of course, this is all just talk until someone(tm) posts a patch > actually making the change. I've looked at the kconfig tool sources > before; not going to make the same mistake again. Right. OTOH whoever implements it gets to pick the color of the bikeshed. ;-) Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/36] dt-bindings: display: look for dsi* nodes in dsi-controller
Hi Linus. On Thu, Apr 16, 2020 at 01:26:32PM +0200, Linus Walleij wrote: > On Wed, Apr 8, 2020 at 9:51 PM Sam Ravnborg wrote: > > > Rob wrote: > > > > Uhhh, it's looking for dsi-controller(@.*)? which is not the common > > case found in dts files. We should fix that to dsi(@.*)?. > > > > See: https://lore.kernel.org/dri-devel/2020031903.GK29911@bogus/ > > > > Fix it. > > > > Signed-off-by: Sam Ravnborg > > Cc: Linus Walleij > > Cc: Rob Herring > > I think I was instructed to use dsi-controller@ at some point but I > suppose it was a misunderstanding. > Acked-by: Linus Walleij I have already applied this and most other patches. I tried to post a follow-up on the first mail to tell so, but it was flagged as spam. So this and your other feddback from today did not hit mainline - sorry. But thanks anyway! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Don't free a struct never allocated by drm_gem_fb_init()
W dniu 15.04.2020 o 20:33, Daniel Vetter pisze:
On Wed, Apr 15, 2020 at 7:19 PM Andrzej Pietrasiewicz
wrote:
drm_gem_fb_init() is passed the fb and never allocates it, so it should be
not the one freeing it. As it is now the second call to kfree() is possible
with the same fb. Coverity reported the following:
*** CID 1492613: Memory - corruptions (USE_AFTER_FREE)
/drivers/gpu/drm/drm_gem_framebuffer_helper.c: 230 in
drm_gem_fb_create_with_funcs()
224 fb = kzalloc(sizeof(*fb), GFP_KERNEL);
225 if (!fb)
226 return ERR_PTR(-ENOMEM);
227
228 ret = drm_gem_fb_init_with_funcs(dev, fb, file, mode_cmd,
funcs);
229 if (ret) {
vvv CID 1492613: Memory - corruptions (USE_AFTER_FREE)
vvv Calling "kfree" frees pointer "fb" which has already been freed. [Note:
The source code implementation of the function has been overridden by a user model.]
230 kfree(fb);
231 return ERR_PTR(ret);
232 }
233
234 return fb;
235 }
drm_gem_fb_init_with_funcs() calls drm_gem_fb_init()
drm_gem_fb_init() calls kfree(fb)
Reported-by: coverity-bot
Addresses-Coverity-ID: 1492613 ("Memory - corruptions")
Fixes: f2b816d78a94 ("drm/core: Allow drivers allocate a subclass of struct
drm_framebuffer")
Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index cac15294aef6..ccc2c71fa491 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -76,10 +76,8 @@ drm_gem_fb_init(struct drm_device *dev,
fb->obj[i] = obj[i];
ret = drm_framebuffer_init(dev, fb, funcs);
- if (ret) {
+ if (ret)
drm_err(dev, "Failed to init framebuffer: %d\n", ret);
- kfree(fb);
- }
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/36] dt-bindings: display: convert arm,versatile-tft-panel to DT Schema
On Wed, Apr 8, 2020 at 9:51 PM Sam Ravnborg wrote: > v2: > - Fix entry in MAINTAINERS > > Signed-off-by: Sam Ravnborg > Cc: Linus Walleij > Cc: Thierry Reding > Cc: Sam Ravnborg Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/36] dt-bindings: display: look for dsi* nodes in dsi-controller
On Wed, Apr 8, 2020 at 9:51 PM Sam Ravnborg wrote: > Rob wrote: > > Uhhh, it's looking for dsi-controller(@.*)? which is not the common > case found in dts files. We should fix that to dsi(@.*)?. > > See: https://lore.kernel.org/dri-devel/2020031903.GK29911@bogus/ > > Fix it. > > Signed-off-by: Sam Ravnborg > Cc: Linus Walleij > Cc: Rob Herring I think I was instructed to use dsi-controller@ at some point but I suppose it was a misunderstanding. Acked-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 0/6] Fix misspellings of "Analog Devices"
Hi all,
In several files the company also known as ADI is spelled as "Analog
Device". However, according to https://www.analog.com/, the company
name is spelled "Analog Devices".
Hence this patch series, one per subsystem, fixes these misspellings.
Thanks for your comments!
Geert Uytterhoeven (6):
dt-bindings: Fix misspellings of "Analog Devices"
dma: Fix misspelling of "Analog Devices"
drm: Fix misspellings of "Analog Devices"
iio: Fix misspellings of "Analog Devices"
ALSA: Fix misspellings of "Analog Devices"
ASoC: Fix misspellings of "Analog Devices"
.../devicetree/bindings/display/bridge/adi,adv7123.txt| 4 ++--
.../devicetree/bindings/display/bridge/adi,adv7511.txt| 4 ++--
Documentation/devicetree/bindings/dma/adi,axi-dmac.txt| 2 +-
Documentation/devicetree/bindings/iio/dac/ad5755.txt | 2 +-
drivers/dma/Kconfig | 2 +-
drivers/gpu/drm/bridge/adv7511/Kconfig| 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/iio/adc/ad7791.c | 2 +-
drivers/iio/trigger/iio-trig-hrtimer.c| 2 +-
drivers/staging/iio/Documentation/overview.txt| 2 +-
sound/isa/ad1816a/ad1816a.c | 2 +-
sound/pci/ac97/ac97_patch.c | 2 +-
sound/pci/hda/Kconfig | 4 ++--
sound/soc/codecs/ad1980.c | 2 +-
sound/soc/codecs/ad73311.c| 2 +-
sound/soc/codecs/wm8782.c | 2 +-
17 files changed, 20 insertions(+), 20 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 1/6] dt-bindings: Fix misspellings of "Analog Devices"
According to https://www.analog.com/, the company name is spelled "Analog Devices". Signed-off-by: Geert Uytterhoeven --- .../devicetree/bindings/display/bridge/adi,adv7123.txt| 4 ++-- .../devicetree/bindings/display/bridge/adi,adv7511.txt| 4 ++-- Documentation/devicetree/bindings/dma/adi,axi-dmac.txt| 2 +- Documentation/devicetree/bindings/iio/dac/ad5755.txt | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt index a6b2b2b8f3d9e3a6..d3c2a4914ea2c247 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt @@ -1,5 +1,5 @@ -Analog Device ADV7123 Video DAC +Analog Devices ADV7123 Video DAC + The ADV7123 is a digital-to-analog converter that outputs VGA signals from a parallel video input. diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index e8ddec5d9d910a5a..659523f538bfc0ee 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -1,5 +1,5 @@ -Analog Device ADV7511(W)/13/33/35 HDMI Encoders -- +Analog Devices ADV7511(W)/13/33/35 HDMI Encoders + The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space diff --git a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt b/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt index b38ee732efa9fd5f..cd17684aaab5bcd3 100644 --- a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt +++ b/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt @@ -1,4 +1,4 @@ -Analog Device AXI-DMAC DMA controller +Analog Devices AXI-DMAC DMA controller Required properties: - compatible: Must be "adi,axi-dmac-1.00.a". diff --git a/Documentation/devicetree/bindings/iio/dac/ad5755.txt b/Documentation/devicetree/bindings/iio/dac/ad5755.txt index f0bbd7e1029bd44d..502e1e55adbdebd0 100644 --- a/Documentation/devicetree/bindings/iio/dac/ad5755.txt +++ b/Documentation/devicetree/bindings/iio/dac/ad5755.txt @@ -1,4 +1,4 @@ -* Analog Device AD5755 IIO Multi-Channel DAC Linux Driver +* Analog Devices AD5755 IIO Multi-Channel DAC Linux Driver Required properties: - compatible: Has to contain one of the following: -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 5/6] ALSA: Fix misspellings of "Analog Devices"
According to https://www.analog.com/, the company name is spelled
"Analog Devices".
Signed-off-by: Geert Uytterhoeven
---
sound/isa/ad1816a/ad1816a.c | 2 +-
sound/pci/ac97/ac97_patch.c | 2 +-
sound/pci/hda/Kconfig | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/isa/ad1816a/ad1816a.c b/sound/isa/ad1816a/ad1816a.c
index ce4c8ba2fa9873e7..ca18fe3ff8a59a9f 100644
--- a/sound/isa/ad1816a/ad1816a.c
+++ b/sound/isa/ad1816a/ad1816a.c
@@ -54,7 +54,7 @@ MODULE_PARM_DESC(clockfreq, "Clock frequency for ad1816a
driver (default = 0).")
static const struct pnp_card_device_id snd_ad1816a_pnpids[] = {
/* Analog Devices AD1815 */
{ .id = "ADS7150", .devs = { { .id = "ADS7150" }, { .id = "ADS7151" } }
},
- /* Analog Device AD1816? */
+ /* Analog Devices AD1816? */
{ .id = "ADS7180", .devs = { { .id = "ADS7180" }, { .id = "ADS7181" } }
},
/* Analog Devices AD1816A - added by Kenneth Platz */
{ .id = "ADS7181", .devs = { { .id = "ADS7180" }, { .id = "ADS7181" } }
},
diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
index ebf926728c5f84af..45ef0f52ec55b803 100644
--- a/sound/pci/ac97/ac97_patch.c
+++ b/sound/pci/ac97/ac97_patch.c
@@ -1356,7 +1356,7 @@ static int patch_cx20551(struct snd_ac97 *ac97)
}
/*
- * Analog Device AD18xx, AD19xx codecs
+ * Analog Devices AD18xx, AD19xx codecs
*/
#ifdef CONFIG_PM
static void ad18xx_resume(struct snd_ac97 *ac97)
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index e1d3082a4fe93153..7ba542e45a3d7f88 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -99,10 +99,10 @@ comment "Set to Y if you want auto-loading the codec driver"
depends on SND_HDA=y && SND_HDA_CODEC_REALTEK=m
config SND_HDA_CODEC_ANALOG
- tristate "Build Analog Device HD-audio codec support"
+ tristate "Build Analog Devices HD-audio codec support"
select SND_HDA_GENERIC
help
- Say Y or M here to include Analog Device HD-audio codec support in
+ Say Y or M here to include Analog Devices HD-audio codec support in
snd-hda-intel driver, such as AD1986A.
comment "Set to Y if you want auto-loading the codec driver"
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 2/6] dma: Fix misspelling of "Analog Devices"
According to https://www.analog.com/, the company name is spelled "Analog Devices". Signed-off-by: Geert Uytterhoeven --- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0924836443152fb5..c35c0e03b40f026b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -106,7 +106,7 @@ config AXI_DMAC select REGMAP_MMIO help Enable support for the Analog Devices AXI-DMAC peripheral. This DMA - controller is often used in Analog Device's reference designs for FPGA + controller is often used in Analog Devices' reference designs for FPGA platforms. config BCM_SBA_RAID -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 3/6] drm: Fix misspellings of "Analog Devices"
According to https://www.analog.com/, the company name is spelled "Analog Devices". Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +- drivers/gpu/drm/drm_fb_cma_helper.c| 2 +- drivers/gpu/drm/tegra/fb.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig b/drivers/gpu/drm/bridge/adv7511/Kconfig index 47d4eb9e845d085c..f46a5e26b5dd6406 100644 --- a/drivers/gpu/drm/bridge/adv7511/Kconfig +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig @@ -6,7 +6,7 @@ config DRM_I2C_ADV7511 select REGMAP_I2C select DRM_MIPI_DSI help - Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders. + Support for the Analog Devices ADV7511(W)/13/33/35 HDMI encoders. config DRM_I2C_ADV7511_AUDIO bool "ADV7511 HDMI Audio driver" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 9801c0333eca29e9..cb2349ad338d953b 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -2,7 +2,7 @@ /* * drm kms/fb cma (contiguous memory allocator) helper functions * - * Copyright (C) 2012 Analog Device Inc. + * Copyright (C) 2012 Analog Devices Inc. * Author: Lars-Peter Clausen * * Based on udl_fbdev.c diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c index b8a328f538626e7a..2b0666ac681b8721 100644 --- a/drivers/gpu/drm/tegra/fb.c +++ b/drivers/gpu/drm/tegra/fb.c @@ -4,7 +4,7 @@ * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved. * * Based on the KMS/FB CMA helpers - * Copyright (C) 2012 Analog Device Inc. + * Copyright (C) 2012 Analog Devices Inc. */ #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 4/6] iio: Fix misspellings of "Analog Devices"
According to https://www.analog.com/, the company name is spelled
"Analog Devices".
Signed-off-by: Geert Uytterhoeven
---
drivers/iio/adc/ad7791.c | 2 +-
drivers/iio/trigger/iio-trig-hrtimer.c | 2 +-
drivers/staging/iio/Documentation/overview.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/ad7791.c b/drivers/iio/adc/ad7791.c
index abb2393926317087..70bfc41052db2740 100644
--- a/drivers/iio/adc/ad7791.c
+++ b/drivers/iio/adc/ad7791.c
@@ -444,5 +444,5 @@ static struct spi_driver ad7791_driver = {
module_spi_driver(ad7791_driver);
MODULE_AUTHOR("Lars-Peter Clausen ");
-MODULE_DESCRIPTION("Analog Device AD7787/AD7788/AD7789/AD7790/AD7791 ADC
driver");
+MODULE_DESCRIPTION("Analog Devices AD7787/AD7788/AD7789/AD7790/AD7791 ADC
driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
b/drivers/iio/trigger/iio-trig-hrtimer.c
index a5e670726717f0d8..f59bf8d585866ea2 100644
--- a/drivers/iio/trigger/iio-trig-hrtimer.c
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -4,7 +4,7 @@
*
* Copyright (C) Intuitive Aerial AB
* Written by Marten Svanfeldt, mar...@intuitiveaerial.com
- * Copyright (C) 2012, Analog Device Inc.
+ * Copyright (C) 2012, Analog Devices Inc.
* Author: Lars-Peter Clausen
* Copyright (C) 2015, Intel Corporation
*/
diff --git a/drivers/staging/iio/Documentation/overview.txt
b/drivers/staging/iio/Documentation/overview.txt
index 43f92b06bc3e5574..ebdc64f451d7c798 100644
--- a/drivers/staging/iio/Documentation/overview.txt
+++ b/drivers/staging/iio/Documentation/overview.txt
@@ -34,7 +34,7 @@ turned on or off (if possible) via sysfs interfaces.
fifo / ring buffers on the sensor chip. These greatly reduce the load
on the host CPU by buffering relatively large numbers of data samples
based on an internal sampling clock. Examples include VTI SCA3000
-series and Analog Device ADXL345 accelerometers. Each buffer supports
+series and Analog Devices ADXL345 accelerometers. Each buffer supports
polling to establish when data is available.
* Trigger and software buffer support. In many data analysis
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH trivial 6/6] ASoC: Fix misspellings of "Analog Devices"
According to https://www.analog.com/, the company name is spelled "Analog Devices". Signed-off-by: Geert Uytterhoeven --- sound/soc/codecs/ad1980.c | 2 +- sound/soc/codecs/ad73311.c | 2 +- sound/soc/codecs/wm8782.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index c4414c725c1f945a..43b1337bac37f70f 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -2,7 +2,7 @@ /* * ad1980.c -- ALSA Soc AD1980 codec support * - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Roy Huang * Cliff Cai */ diff --git a/sound/soc/codecs/ad73311.c b/sound/soc/codecs/ad73311.c index 10daf61f02940b46..b98bf19f594e097f 100644 --- a/sound/soc/codecs/ad73311.c +++ b/sound/soc/codecs/ad73311.c @@ -2,7 +2,7 @@ /* * ad73311.c -- ALSA Soc AD73311 codec support * - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Cliff Cai */ diff --git a/sound/soc/codecs/wm8782.c b/sound/soc/codecs/wm8782.c index aa5577e364d01360..f89855c616ebe6e6 100644 --- a/sound/soc/codecs/wm8782.c +++ b/sound/soc/codecs/wm8782.c @@ -7,7 +7,7 @@ * Author: Johannes Stezenbach * * based on ad73311.c - * Copyright: Analog Device Inc. + * Copyright: Analog Devices Inc. * Author: Cliff Cai */ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: android: ion: Skip sync if not mapped
On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> On Tue, Apr 14, 2020 at 7:28 AM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > > Only sync the sg-list of an Ion dma-buf attachment when the attachment
> > > is actually mapped on the device.
> > >
> > > dma-bufs may be synced at any time. It can be reached from user space
> > > via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
> > > syncs may be attempted, and dma_buf_end_cpu_access() and
> > > dma_buf_begin_cpu_access() may not be paired.
> > >
> > > Since the sg_list's dma_address isn't set up until the buffer is used
> > > on the device, and dma_map_sg() is called on it, the dma_address will be
> > > NULL if sync is attempted on the dma-buf before it's mapped on a device.
> > >
> > > Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
> > > into the dma_direct code")) this was a problem as the dma-api (at least
> > > the swiotlb_dma_ops on arm64) would use the potentially invalid
> > > dma_address. How that failed depended on how the device handled physical
> > > address 0. If 0 was a valid address to physical ram, that page would get
> > > flushed a lot, while the actual pages in the buffer would not get synced
> > > correctly. While if 0 is an invalid physical address it may cause a
> > > fault and trigger a crash.
> > >
> > > In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
> > > merge swiotlb_dma_ops into the dma_direct code"), as this moved the
> > > dma-api to use the page pointer in the sg_list, and (for Ion buffers at
> > > least) this will always be valid if the sg_list exists at all.
> > >
> > > But, this issue is re-introduced in v5.3 with
> > > commit 449fa54d6815 ("dma-direct: correct the physical addr in
> > > dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
> > > behaviour and picks the dma_address that may be invalid.
> > >
> > > dma-buf core doesn't ensure that the buffer is mapped on the device, and
> > > thus have a valid sg_list, before calling the exporter's
> > > begin_cpu_access.
> > >
> > > Signed-off-by: Ørjan Eide
> > > ---
> > > drivers/staging/android/ion/ion.c | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > Resubmit without disclaimer, sorry about that.
> > >
> > > This seems to be part of a bigger issue where dma-buf exporters assume
> > > that their dma-buf begin_cpu_access and end_cpu_access callbacks have a
> > > certain guaranteed behavior, which isn't ensured by dma-buf core.
> > >
> > > This patch fixes this in ion only, but it also needs to be fixed for
> > > other exporters, either handled like this in each exporter, or in
> > > dma-buf core before calling into the exporters.
> > >
> > > diff --git a/drivers/staging/android/ion/ion.c
> > > b/drivers/staging/android/ion/ion.c
> > > index 38b51eace4f9..7b752ba0cb6d 100644
> > > --- a/drivers/staging/android/ion/ion.c
> > > +++ b/drivers/staging/android/ion/ion.c
> >
> > Now that we have the dma-buff stuff in the tree, do we even need the
> > ion code in the kernel anymore? Can't we delete it now?
> >
>
> I agree that we shouldn't be taking further (non-security/cleanup)
> patches to the ION code.
>
> I'd like to give developers a little bit of a transition period (I was
> thinking a year, but really just one LTS release that has both would
> do) where they can move their ION heaps over to dmabuf heaps and test
> both against the same tree.
>
> But I do think we can mark it as deprecated and let folks know that
> around the end of the year it will be deleted.
No one ever notices "depreciated" things, they only notice if the code
is no longer there :)
So I'm all for just deleting it and seeing who even notices...
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, 16 Apr 2020, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed wrote: >> BTW how about adding a new Kconfig option to hide the details of >> ( BAR || !BAR) ? as Jason already explained and suggested, this will >> make it easier for the users and developers to understand the actual >> meaning behind this tristate weird condition. >> >> e.g have a new keyword: >> reach VXLAN >> which will be equivalent to: >> depends on VXLAN && !VXLAN > > I'd love to see that, but I'm not sure what keyword is best. For your > suggestion of "reach", that would probably do the job, but I'm not > sure if this ends up being more or less confusing than what we have > today. Ah, perfect bikeshedding topic! Perhaps "uses"? If the dependency is enabled it gets used as a dependency. Of course, this is all just talk until someone(tm) posts a patch actually making the change. I've looked at the kconfig tool sources before; not going to make the same mistake again. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: android: ion: Skip sync if not mapped
On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> @@ -238,6 +242,10 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment
> *attachment,
> struct sg_table *table,
> enum dma_data_direction direction)
> {
> + struct ion_dma_buf_attachment *a = attachment->priv;
> +
> + a->mapped = false;
Possibly a stupid question but here we're not holding a lock. Is
concurrency an issue?
> +
> dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> }
>
> @@ -297,6 +305,8 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
> *dmabuf,
>
> mutex_lock(>lock);
> list_for_each_entry(a, >attachments, list) {
> + if (!a->mapped)
> + continue;
> dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
> direction);
> }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 09/11] backlight: pwm_bl: Use 64-bit division function
On Wed, 08 Apr 2020, Guru Das Srinagesh wrote: > Since the PWM framework is switching struct pwm_state.period's datatype > to u64, prepare for this transition by using div_u64 to handle a 64-bit > dividend instead of a straight division operation. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > > Signed-off-by: Guru Das Srinagesh > Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/pwm_bl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) I see that this is part of a large set, but the remainder of the patches have been hidden from me. Does this mean I can apply this patch on its own? > diff --git a/drivers/video/backlight/pwm_bl.c > b/drivers/video/backlight/pwm_bl.c > index efb4efc..3e5dbcf 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device > *pdev) > pb->scale = data->max_brightness; > } > > - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); > + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, > + pb->scale)); > > props.type = BACKLIGHT_RAW; > props.max_brightness = data->max_brightness; -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
UAPI doc (Re: KMS enums and bitfields UAPI)
On Wed, 15 Apr 2020 10:40:36 + Simon Ser wrote: > On Tuesday, April 14, 2020 3:33 PM, Daniel Vetter wrote: > > > > What I'm suggesting isn't to make all enum values UAPI. I'm suggesting > > > to add standard enum values as #defines in the UAPI headers to make > > > these values UAPI. Non-standard properties wouldn't be in the UAPI > > > headers, so user-space would need to query values from KMS just like > > > they do now. > > > > Hm that sounds like the half-way that wont work. Because then some > > compositors will only use the hard-coded versions, and if they don't > > have them, nag us to add them. And then be really disappointed if we > > don't (or we screw up and add them where we shouldn't). That's the > > status quo "let's have it both ways" that I think is the worst of all > > options we have. So I guess from that pov the "userspace needs to > > decode from symbolic values, always" as the only consistent one. > > Fair enough. Let's just continue using symbolic names then. Hi, I'm happy to see a decision made that is clear and simple, even if it makes userspace need a little more code. We as userspace programmers have a huge responsibility of figuring out exactly how KMS UAPI is supposed to be used, and use it correctly, because the UAPI is largely undocumented and whatever documentation exists is not easily discoverable to a non-kernel developer. Libdrm has a few man-pages that seem to have been left to rot. If I could, bringing them up-to-date and extending to cover everything about driver-agnostic KMS UAPI would seem like a nice idea. It would be the obvious place for userspace oriented docs. After all, UAPI docs cannot become incorrect over time (the stable UAPI promise), so the maintenance effort would be just adding the new stuff and if necessary, clarifying old stuff. No confusion with any kernel internal API that is subject to change at any time. https://www.kernel.org/doc/html/latest/ is really hard to find anything in it when you need it. Often the terms you need to search for are not the ones used in the UAPI or have far too many hits, assuming you know what UAPI you would want to use in the first place. Another disconnect is that libdrm API is not the UAPI exactly. So documenting libdrm API with the kernel UAPI in mind would be the best. People use libdrm more than kernel UAPI. Thanks, pq pgpI3US62dAO_.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/12] arm: dts: s5pv210: Add G3D node
On Wed, Apr 15, 2020 at 11:17:16AM -0700, Jonathan Bakker wrote: > >> > >>> + > >>> + assigned-clocks = < MOUT_G3D>, < > >>> DOUT_G3D>; > >>> + assigned-clock-rates = <0>, <6670>; > >>> + assigned-clock-parents = < MOUT_MPLL>; > >> > >> Probably this should have status disabled because you do not set > >> regulator supply. > > I don't believe there is a regulator on s5pv210, if there is, then it is a > fixed regulator with no control on both s5pv210 devices that I have. > > The vendor driver did use the regulator framework for its power domain > implementation, but that definitely shouldn't be upstreamed. Starting with Exynos4210 usually they have separate regulator from PMIC but maybe S5Pv210 indeed is different. Leave it then without it. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gt: remove redundant assignment to variable x
On Wed, Apr 15, 2020 at 12:07:44PM +0300, Jani Nikula wrote: > On Tue, 14 Apr 2020, Colin Ian King wrote: > > Hi Dan, > > > > I'd post a revert, but I don't seem to see an upstream commit for this > > this to revert against. What's the revert policy in these cases? Or can > > the patch be just ignored by the maintainers so it's not applied? > > It has not been applied, and will be ignored, in part thanks to the > report. > > However I think Dan's report is misleading in that it looks like it's > about a commit while I think it should emphasize that it's a pre-merge > report on the patch on the mailing list. > To be honest, these are auto-generated by the kbuild bot and I was a bit confused myself. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On 15-04-20, 19:55, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/altera.yaml | 6 +- > .../amlogic/amlogic,meson-gx-ao-secure.yaml | 2 +- > .../devicetree/bindings/arm/bitmain.yaml | 2 +- > .../devicetree/bindings/arm/nxp/lpc32xx.yaml | 9 ++- > .../bindings/arm/socionext/uniphier.yaml | 26 > .../bindings/arm/stm32/st,mlahb.yaml | 2 +- > .../bindings/arm/stm32/st,stm32-syscon.yaml | 6 +- > .../bindings/ata/faraday,ftide010.yaml| 4 +- > .../bindings/bus/allwinner,sun8i-a23-rsb.yaml | 4 +- > .../clock/allwinner,sun4i-a10-gates-clk.yaml | 8 +-- > .../devicetree/bindings/clock/fsl,plldig.yaml | 17 +++-- > .../devicetree/bindings/clock/qcom,mmcc.yaml | 16 ++--- > .../bindings/connector/usb-connector.yaml | 6 +- > .../crypto/allwinner,sun4i-a10-crypto.yaml| 14 ++-- > .../bindings/crypto/allwinner,sun8i-ce.yaml | 16 ++--- > .../bindings/crypto/amlogic,gxl-crypto.yaml | 2 +- > .../display/allwinner,sun4i-a10-hdmi.yaml | 40 ++-- > .../display/allwinner,sun4i-a10-tcon.yaml | 58 - > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 10 +-- > .../bindings/display/bridge/lvds-codec.yaml | 18 +++--- > .../display/panel/sony,acx424akp.yaml | 2 +- > .../display/panel/xinpeng,xpp055c272.yaml | 4 +- > .../bindings/display/renesas,cmm.yaml | 16 ++--- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 8 +-- Acked-By: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On 15-04-20, 19:55, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/cpus.yaml | 81 +++--- > .../devicetree/bindings/arm/l2c2x0.yaml | 87 +++--- > .../devicetree/bindings/arm/psci.yaml | 15 +- > .../bindings/arm/samsung/exynos-chipid.yaml | 5 +- > .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- > .../bindings/clock/fixed-factor-clock.yaml| 5 +- > .../bindings/connector/usb-connector.yaml | 28 +- > .../bindings/crypto/st,stm32-hash.yaml| 9 +- > .../allwinner,sun4i-a10-display-engine.yaml | 7 +- > .../display/allwinner,sun4i-a10-tcon.yaml | 5 +- > .../bindings/display/panel/panel-common.yaml | 5 +- > .../devicetree/bindings/dma/dma-common.yaml | 3 +- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 18 +- Acked-By: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Thu, Apr 16, 2020 at 2:55 AM Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring Reviewed-by: Linus Walleij Thanks for fixing this! Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Fix regression by audio component transition
Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component
notifier support"), the nouveau driver notifies and pokes the HD-audio
HPD and ELD via audio component, but this seems broken. The culprit
is the naive assumption that crtc->index corresponds to the HDA pin.
Actually this rather corresponds to the MST dev_id (alias "pipe" in
the audio component framework) while the actual port number is given
from the output ior id number.
This patch corrects the assignment of port and dev_id arguments in the
audio component ops to recover from the HDMI/DP audio regression.
Fixes: 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
Cc:
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index a3dc2ba19fb2..3a9fd565079d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -481,15 +481,16 @@ nv50_dac_create(struct drm_connector *connector, struct
dcb_output *dcbe)
* audio component binding for ELD notification
*/
static void
-nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int port)
+nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int port,
+ int dev_id)
{
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
-port, -1);
+port, dev_id);
}
static int
-nv50_audio_component_get_eld(struct device *kdev, int port, int pipe,
+nv50_audio_component_get_eld(struct device *kdev, int port, int dev_id,
bool *enabled, unsigned char *buf, int max_bytes)
{
struct drm_device *drm_dev = dev_get_drvdata(kdev);
@@ -505,7 +506,8 @@ nv50_audio_component_get_eld(struct device *kdev, int port,
int pipe,
nv_encoder = nouveau_encoder(encoder);
nv_connector = nouveau_encoder_connector_get(nv_encoder);
nv_crtc = nouveau_crtc(encoder->crtc);
- if (!nv_connector || !nv_crtc || nv_crtc->index != port)
+ if (!nv_connector || !nv_crtc || nv_encoder->or != port ||
+ nv_crtc->index != dev_id)
continue;
*enabled = drm_detect_monitor_audio(nv_connector->edid);
if (*enabled) {
@@ -599,7 +601,8 @@ nv50_audio_disable(struct drm_encoder *encoder, struct
nouveau_crtc *nv_crtc)
nvif_mthd(>disp->object, 0, , sizeof(args));
- nv50_audio_component_eld_notify(drm->audio.component, nv_crtc->index);
+ nv50_audio_component_eld_notify(drm->audio.component, nv_encoder->or,
+ nv_crtc->index);
}
static void
@@ -633,7 +636,8 @@ nv50_audio_enable(struct drm_encoder *encoder, struct
drm_display_mode *mode)
nvif_mthd(>disp->object, 0, ,
sizeof(args.base) + drm_eld_size(args.data));
- nv50_audio_component_eld_notify(drm->audio.component, nv_crtc->index);
+ nv50_audio_component_eld_notify(drm->audio.component, nv_encoder->or,
+ nv_crtc->index);
}
/**
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. > > Signed-off-by: Rob Herring Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, 15 Apr 2020, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/cpus.yaml | 81 +++--- > .../devicetree/bindings/arm/l2c2x0.yaml | 87 +++--- > .../devicetree/bindings/arm/psci.yaml | 15 +- > .../bindings/arm/samsung/exynos-chipid.yaml | 5 +- > .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- > .../bindings/clock/fixed-factor-clock.yaml| 5 +- > .../bindings/connector/usb-connector.yaml | 28 +- > .../bindings/crypto/st,stm32-hash.yaml| 9 +- > .../allwinner,sun4i-a10-display-engine.yaml | 7 +- > .../display/allwinner,sun4i-a10-tcon.yaml | 5 +- > .../bindings/display/panel/panel-common.yaml | 5 +- > .../devicetree/bindings/dma/dma-common.yaml | 3 +- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 18 +- > .../devicetree/bindings/eeprom/at24.yaml | 11 +- > .../devicetree/bindings/example-schema.yaml | 17 +- > .../bindings/hwmon/adi,ltc2947.yaml | 32 +-- > .../devicetree/bindings/hwmon/ti,tmp513.yaml | 21 +- > .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 9 +- > .../bindings/iio/adc/adi,ad7124.yaml | 5 +- > .../bindings/iio/adc/lltc,ltc2496.yaml| 3 +- > .../bindings/iio/adc/microchip,mcp3911.yaml | 7 +- > .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 31 +- > .../bindings/iio/light/tsl2772.yaml | 13 +- > .../bindings/iio/temperature/adi,ltc2983.yaml | 56 ++-- > .../input/allwinner,sun4i-a10-lradc-keys.yaml | 5 +- > .../devicetree/bindings/input/input.yaml | 9 +- > .../interrupt-controller/arm,gic-v3.yaml | 39 ++- > .../devicetree/bindings/iommu/arm,smmu.yaml | 3 +- > .../devicetree/bindings/leds/common.yaml | 13 +- > .../devicetree/bindings/leds/leds-gpio.yaml | 3 +- > .../bindings/leds/rohm,bd71828-leds.yaml | 10 +- > .../bindings/mailbox/st,stm32-ipcc.yaml | 5 +- > .../bindings/media/amlogic,gx-vdec.yaml | 6 +- > .../media/amlogic,meson-gx-ao-cec.yaml| 3 +- > .../devicetree/bindings/media/rc.yaml | 265 +- > .../bindings/media/renesas,vin.yaml | 7 +- > .../memory-controllers/exynos-srom.yaml | 14 +- > .../nvidia,tegra124-emc.yaml | 9 +- > .../nvidia,tegra124-mc.yaml | 3 +- > .../nvidia,tegra30-emc.yaml | 9 +- > .../memory-controllers/nvidia,tegra30-mc.yaml | 3 +- > .../bindings/mfd/allwinner,sun4i-a10-ts.yaml | 20 +- > .../bindings/mfd/st,stm32-timers.yaml | 33 ++- > .../devicetree/bindings/mfd/st,stpmic1.yaml | 9 +- > .../devicetree/bindings/mfd/syscon.yaml | 5 +- Acked-by: Lee Jones > .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 4 +- > .../devicetree/bindings/mmc/cdns,sdhci.yaml | 77 +++-- > .../bindings/mmc/mmc-controller.yaml | 37 ++- > .../bindings/mmc/rockchip-dw-mshc.yaml| 6 +- > .../bindings/mmc/synopsys-dw-mshc-common.yaml | 14 +- > .../mtd/allwinner,sun4i-a10-nand.yaml | 13 +- > .../bindings/mtd/nand-controller.yaml | 27 +- > .../bindings/net/can/bosch,m_can.yaml | 59 ++-- > .../bindings/net/ethernet-controller.yaml | 34 +-- > .../devicetree/bindings/net/qca,ar803x.yaml | 17 +- > .../devicetree/bindings/net/snps,dwmac.yaml | 22 +- > .../bindings/net/ti,cpsw-switch.yaml | 3 +- > .../bindings/net/ti,davinci-mdio.yaml | 7 +- > .../bindings/pci/intel-gw-pcie.yaml | 7 +- > .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 12 +- > .../pinctrl/aspeed,ast2400-pinctrl.yaml | 37 ++- > .../pinctrl/aspeed,ast2500-pinctrl.yaml | 45 ++- > .../pinctrl/aspeed,ast2600-pinctrl.yaml | 108 --- > .../bindings/pinctrl/fsl,imx8mp-pinctrl.yaml | 31 +- > .../bindings/pinctrl/intel,lgm-io.yaml| 4 +- > .../bindings/pinctrl/pinmux-node.yaml | 3 +- > .../bindings/pinctrl/st,stm32-pinctrl.yaml| 56 ++-- > .../bindings/power/amlogic,meson-ee-pwrc.yaml | 3 +- > .../devicetree/bindings/pwm/pwm-samsung.yaml | 11 +- > .../bindings/regulator/gpio-regulator.yaml| 35 ++- > .../bindings/regulator/mps,mpq7920.yaml | 31 +- > .../bindings/regulator/regulator.yaml | 5 +- > .../regulator/rohm,bd71828-regulator.yaml | 34 +-- > .../bindings/regulator/st,stm32-booster.yaml | 3 +- >
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed wrote: > > On Tue, 2020-04-14 at 20:47 +0200, Arnd Bergmann wrote: > > On Tue, Apr 14, 2020 at 7:49 PM Saeed Mahameed > > wrote: > > > On Tue, 2020-04-14 at 17:25 +0200, Arnd Bergmann wrote: > > > > On Tue, Apr 14, 2020 at 5:23 PM Jason Gunthorpe > > > > wrote: > > > > Correct. > > > > > > > > > > Great ! > > > > > > Then bottom line we will change mlx5/Kconfig: to > > > > > > depends on VXLAN || !VXLAN > > > > Ok > > > > BTW how about adding a new Kconfig option to hide the details of > ( BAR || !BAR) ? as Jason already explained and suggested, this will > make it easier for the users and developers to understand the actual > meaning behind this tristate weird condition. > > e.g have a new keyword: > reach VXLAN > which will be equivalent to: > depends on VXLAN && !VXLAN I'd love to see that, but I'm not sure what keyword is best. For your suggestion of "reach", that would probably do the job, but I'm not sure if this ends up being more or less confusing than what we have today. > > > This will force MLX5_CORE to m when necessary to make vxlan > > > reachable > > > to mlx5_core. So no need for explicit use of IS_REACHABLE(). > > > in mlx5 there are 4 of these: > > > > > > imply PTP_1588_CLOCK > > > imply VXLAN > > > imply MLXFW > > > imply PCI_HYPERV_INTERFACE > > > > As mentioned earlier, we do need to replace the 'imply > > PTP_1588_CLOCK' > > with the same > > > > depends on PTP_1588_CLOCK || !PTP_1588_CLOCK > > > > So far I have not seen problems for the other two options, so I > > assume they > > are fine for now -- it seems to build just fine without > > PCI_HYPERV_INTERFACE, > > and MLXFW has no other dependencies, meaning that 'imply' is the > > same as 'select' here. Using 'select MLXFW' would make it clearer > > perhaps. > > No, I would like to avoid select and allow building mlx5 without MLXFW, > MLXFW already has a stub protected with IS_REACHABLE(), this is why we > don't have an issue with it. So the 'imply MLXFW' should be dropped then? Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On Wed, 15 Apr 2020, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. > > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/altera.yaml | 6 +- > .../amlogic/amlogic,meson-gx-ao-secure.yaml | 2 +- > .../devicetree/bindings/arm/bitmain.yaml | 2 +- > .../devicetree/bindings/arm/nxp/lpc32xx.yaml | 9 ++- > .../bindings/arm/socionext/uniphier.yaml | 26 > .../bindings/arm/stm32/st,mlahb.yaml | 2 +- > .../bindings/arm/stm32/st,stm32-syscon.yaml | 6 +- > .../bindings/ata/faraday,ftide010.yaml| 4 +- > .../bindings/bus/allwinner,sun8i-a23-rsb.yaml | 4 +- > .../clock/allwinner,sun4i-a10-gates-clk.yaml | 8 +-- > .../devicetree/bindings/clock/fsl,plldig.yaml | 17 +++-- > .../devicetree/bindings/clock/qcom,mmcc.yaml | 16 ++--- > .../bindings/connector/usb-connector.yaml | 6 +- > .../crypto/allwinner,sun4i-a10-crypto.yaml| 14 ++-- > .../bindings/crypto/allwinner,sun8i-ce.yaml | 16 ++--- > .../bindings/crypto/amlogic,gxl-crypto.yaml | 2 +- > .../display/allwinner,sun4i-a10-hdmi.yaml | 40 ++-- > .../display/allwinner,sun4i-a10-tcon.yaml | 58 - > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 10 +-- > .../bindings/display/bridge/lvds-codec.yaml | 18 +++--- > .../display/panel/sony,acx424akp.yaml | 2 +- > .../display/panel/xinpeng,xpp055c272.yaml | 4 +- > .../bindings/display/renesas,cmm.yaml | 16 ++--- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 8 +-- > .../bindings/gpio/brcm,xgs-iproc-gpio.yaml| 2 +- > .../bindings/gpu/arm,mali-midgard.yaml| 18 +++--- > .../devicetree/bindings/gpu/vivante,gc.yaml | 2 +- > .../devicetree/bindings/i2c/i2c-rk3x.yaml | 10 +-- > .../bindings/iio/adc/adi,ad7124.yaml | 4 +- > .../bindings/iio/adc/lltc,ltc2496.yaml| 6 +- > .../input/allwinner,sun4i-a10-lradc-keys.yaml | 4 +- > .../bindings/input/touchscreen/goodix.yaml| 2 +- > .../bindings/interconnect/qcom,msm8916.yaml | 4 +- > .../bindings/interconnect/qcom,msm8974.yaml | 4 +- > .../bindings/interconnect/qcom,qcs404.yaml| 4 +- > .../allwinner,sun7i-a20-sc-nmi.yaml | 12 ++-- > .../intel,ixp4xx-interrupt.yaml | 8 +-- > .../interrupt-controller/st,stm32-exti.yaml | 12 ++-- > .../bindings/iommu/samsung,sysmmu.yaml| 10 +-- > .../bindings/mailbox/st,stm32-ipcc.yaml | 2 +- > .../media/allwinner,sun4i-a10-csi.yaml| 28 > .../bindings/media/amlogic,gx-vdec.yaml | 14 ++-- > .../bindings/media/renesas,ceu.yaml | 28 > .../bindings/media/renesas,vin.yaml | 8 +-- > .../devicetree/bindings/media/ti,vpe.yaml | 2 +- > .../memory-controllers/fsl/imx8m-ddrc.yaml| 6 +- > .../bindings/mfd/st,stm32-lptimer.yaml| 4 +- > .../bindings/mfd/st,stm32-timers.yaml | 4 +- > .../devicetree/bindings/mfd/syscon.yaml | 12 ++-- Acked-by: Lee Jones > .../devicetree/bindings/mmc/cdns,sdhci.yaml | 2 +- > .../bindings/mmc/rockchip-dw-mshc.yaml| 16 ++--- > .../bindings/mmc/socionext,uniphier-sd.yaml | 14 ++-- > .../devicetree/bindings/mtd/denali,nand.yaml | 4 +- > .../net/allwinner,sun8i-a83t-emac.yaml| 4 +- > .../bindings/net/can/bosch,m_can.yaml | 52 +++ > .../bindings/net/renesas,ether.yaml | 4 +- > .../bindings/net/ti,cpsw-switch.yaml | 12 ++-- > .../bindings/net/ti,davinci-mdio.yaml | 27 > .../bindings/phy/intel,lgm-emmc-phy.yaml | 2 +- > .../devicetree/bindings/pwm/pwm-samsung.yaml | 16 ++--- > .../bindings/remoteproc/st,stm32-rproc.yaml | 2 +- > .../reset/brcm,bcm7216-pcie-sata-rescal.yaml | 4 +- > .../devicetree/bindings/rtc/st,stm32-rtc.yaml | 38 +-- > .../bindings/serial/amlogic,meson-uart.yaml | 16 ++--- > .../devicetree/bindings/serial/rs485.yaml | 17 ++--- > .../bindings/soc/amlogic/amlogic,canvas.yaml | 10 +-- > .../bindings/sound/renesas,fsi.yaml | 16 ++--- > .../bindings/spi/qcom,spi-qcom-qspi.yaml | 10 +-- > .../devicetree/bindings/spi/renesas,hspi.yaml | 4 +- > .../devicetree/bindings/spi/spi-pl022.yaml| 2 +- > .../bindings/spi/st,stm32-qspi.yaml | 4 +- > .../allwinner,sun4i-a10-system-control.yaml | 64 +-- > .../bindings/thermal/amlogic,thermal.yaml | 10 +-- > .../bindings/timer/arm,arch_timer.yaml| 4 +- > .../bindings/timer/arm,arch_timer_mmio.yaml | 4 +- > .../devicetree/bindings/usb/dwc2.yaml | 8 +-- > 77 files changed, 450 insertions(+), 450 deletions(-) -- Lee Jones [李琼斯]
Re: [PATCH v6 08/12] arm: dts: s5pv210: Add G3D node
> Am 15.04.2020 um 13:49 schrieb Krzysztof Kozlowski :
>
> On Wed, 15 Apr 2020 at 10:36, H. Nikolaus Schaller wrote:
>>
>> From: Jonathan Bakker
>>
>> to add support for SGX540 GPU.
>
> Do not continue the subject in commit msg like it is one sentence.
> These are two separate sentences, so commit msg starts with capital
> letter and it is sentence by itself.
>
>> Signed-off-by: Jonathan Bakker
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/arm/boot/dts/s5pv210.dtsi | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
>> index 2ad642f51fd9..e7fc709c0cca 100644
>> --- a/arch/arm/boot/dts/s5pv210.dtsi
>> +++ b/arch/arm/boot/dts/s5pv210.dtsi
>> @@ -512,6 +512,21 @@ vic3: interrupt-controller@f230 {
>>#interrupt-cells = <1>;
>>};
>>
>> + g3d: g3d@f300 {
>> + compatible = "samsung,s5pv210-sgx540-120";
>> + reg = <0xf300 0x1>;
>> + interrupt-parent = <>;
>> + interrupts = <10>;
>> + clock-names = "sclk";
>> + clocks = < CLK_G3D>;
>
> Not part of bindings, please remove or add to the bindings.
Well, the bindings should describe what is common for all SoC
and they are quite different in what they need in addition.
Thererfore we have no "additionalProperties: false" in the
bindings [PATCH v6 01/12].
>
>> +
>> + power-domains = < S5PV210_PD_G3D>;
>
> Ditto
In this case it might be possible to add the clock/power-domains
etc. to a wrapper node compatible to "simple-pm-bus" or similar
and make the gpu a child of it.
@Jontahan: can you please give it a try?
>
>> +
>> + assigned-clocks = < MOUT_G3D>, <
>> DOUT_G3D>;
>> + assigned-clock-rates = <0>, <6670>;
>> + assigned-clock-parents = < MOUT_MPLL>;
>
> Probably this should have status disabled because you do not set
> regulator supply.
>
> Best regards,
> Krzysztof
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote: > json-schema versions draft7 and earlier have a weird behavior in that > any keywords combined with a '$ref' are ignored (silently). The correct > form was to put a '$ref' under an 'allOf'. This behavior is now changed > in the 2019-09 json-schema spec and '$ref' can be mixed with other > keywords. The json-schema library doesn't yet support this, but the > tooling now does a fixup for this and either way works. > > This has been a constant source of review comments, so let's change this > treewide so everyone copies the simpler syntax. > > Signed-off-by: Rob Herring For allwinner, Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 1/3] drm/panel: simple: Add support for AUO G190EAN01 panel
Add timings for the G190EAN01 dual channel LVDS panel.
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 33 +++
2 files changed, 35 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 8fc117d1547c..7c9a08d846b9 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -59,6 +59,8 @@ properties:
- auo,g133han01
# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
- auo,g185han01
+# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
# AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
- auo,p320hvn03
# AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 44a1f5dfb571..8d1cf68ca01b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -933,6 +933,36 @@ static const struct panel_desc auo_g185han01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct display_timing auo_g190ean01_timings = {
+ .pixelclock = { 9000, 10800, 13500 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 126, 184, 1266 },
+ .hback_porch = { 84, 122, 844 },
+ .hsync_len = { 70, 102, 704 },
+ .vactive = { 1024, 1024, 1024 },
+ .vfront_porch = { 4, 26, 76 },
+ .vback_porch = { 2, 8, 25 },
+ .vsync_len = { 2, 8, 25 },
+};
+
+static const struct panel_desc auo_g190ean01 = {
+ .timings = _g190ean01_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 376,
+ .height = 301,
+ },
+ .delay = {
+ .prepare = 50,
+ .enable = 200,
+ .disable = 110,
+ .unprepare = 1000,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing auo_p320hvn03_timings = {
.pixelclock = { 10600, 14850, 16400 },
.hactive = { 1920, 1920, 1920 },
@@ -3497,6 +3527,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "auo,g185han01",
.data = _g185han01,
+ }, {
+ .compatible = "auo,g190ean01",
+ .data = _g190ean01,
}, {
.compatible = "auo,p320hvn03",
.data = _p320hvn03,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/12] ARM: DTS: omap4: add sgx gpu child node
and add interrupt.
Since omap4420/30/60 and omap4470 come with different SGX variants
we need to introduce a new omap4470.dtsi. If an omap4470 board
does not want to use SGX it is no problem to still include
omap4460.dtsi.
Tested-by: H. Nikolaus Schaller # PandaBoard ES
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap4.dtsi | 11 ++-
arch/arm/boot/dts/omap4470.dts | 15 +++
2 files changed, 21 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4470.dts
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 763bdea8c829..15ff3d7146af 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -389,7 +389,7 @@ abb_iva: regulator-abb-iva {
status = "disabled";
};
- target-module@5600 {
+ sgx_module: target-module@5600 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5600fe00 0x4>,
<0x5600fe10 0x4>;
@@ -408,10 +408,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu: gpu@0 {
+ compatible = "ti,omap4-sgx540-120",
"img,sgx540-120", "img,sgx540";
+ reg = <0x0 0x200>; /* 32MB */
+ interrupts = ;
+ };
};
/*
diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
new file mode 100644
index ..f29c581300bf
--- /dev/null
+++ b/arch/arm/boot/dts/omap4470.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for OMAP4470 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#include "omap4460.dtsi"
+
+ {
+ compatible = "ti,omap4470-sgx544-112", "img,sgx544-112", "img,sgx544";
+};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 0/3] Add multiple AUO panels
Hi, Patches are more or less independent of each other. There was a previous version for the 12" and 15" panels, which was missing the DT binding update. The 19" patch is new, for the previous 10" panel a different patch has been merged in the meantime. -- Sebastian Sebastian Reichel (3): drm/panel: simple: Add support for AUO G190EAN01 panel drm/panel: simple: Add support for AUO G156XTN01.0 panel drm/panel: simple: Add support for AUO G121EAN01.4 panel .../bindings/display/panel/panel-simple.yaml | 6 ++ drivers/gpu/drm/panel/panel-simple.c | 89 +++ 2 files changed, 95 insertions(+) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dpcd: Print more useful information during error
When DPCD access errors occur, knowing the register and request
associated with the error helps debugging, so print the
details in the debug message.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/drm_dp_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c6fbe6e6b..8aafc01f5 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -257,7 +257,9 @@ static int drm_dp_dpcd_access(struct drm_dp_aux
*aux, u8 request,
err = ret;
}
- DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
+ DRM_DEBUG_KMS("dpcd: Too many retries, giving up. First error: %d,"
+ " address: 0x%x, request: 0x%x, size:%zu\n",
+ err, msg.address, msg.request, msg.size);
ret = err;
unlock:
--
2.26.0
On Tue, Apr 14, 2020 at 7:04 AM Jani Nikula wrote:
>
> On Thu, 09 Apr 2020, Aurabindo Pillai wrote:
> > When DPCD access errors occur, knowing the register and request
> > associated with the error helps debugging, so print the
> > details in the debug message.
> >
> > Signed-off-by: Aurabindo Pillai
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index a5364b519..545606aac 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -257,7 +257,9 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux,
> > u8 request,
> > err = ret;
> > }
> >
> > - DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
> > + DRM_DEBUG_KMS("dpcd: Too many retries, giving up. First error: %d\t"
> > + "address: %x\trequest: %x\t size:%zu\n",
> > + err, msg.address, msg.request, msg.size);
>
> Nitpicks, please don't add tabs, maybe use commas instead, and please
> add 0x in front of hex.
>
> BR,
> Jani.
>
>
> > ret = err;
> >
> > unlock:
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Thanks and Regards,
Aurabindo J Pillai
https://aurabindo.in
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Simplefs: group and simplify linux fs code
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote: > This series of patches introduce wrappers for functions, > arguments simplification in functions calls and most importantly > groups duplicated code in a single header, simplefs, to avoid redundancy > in the linux fs, especially debugfs and tracefs. The general goal seems worthy, but here I don't see explained why hasn't this gone through libfs, and what the intention was long term. For instance, you added some other generalizations which you have found. It was not clear that this was the goal here, to expand on these paths. What if common code on fs is found which are not part of debugfs and tracefs, how does one decide if to move to libfs or simplefs? Luis ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
