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: 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
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
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: [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
[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
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: [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: 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 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/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: [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
[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: [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 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 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 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 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: [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 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 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] 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 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 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 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
[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, 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 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
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 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 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
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 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
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
[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
[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
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
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] 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: [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] 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
