[Intel-gfx] [PATCH] MAINTAINERS: update the 01.org website entries
The 01.org links in MAINTAINERS now forward to different other pages or do not resolve. The link https://01.org/linuxgraphics/ resolves to the Intel Graphics for Linux - Programmer's Reference Manuals. Update this webpage entry. The link https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html does not resolve. Remove this webpage entry. The link https://01.org/igvt-g resolves to https://github.com/intel/gvt-linux. Remove the webpage entry, as the github repository is already referred to by the T: entry in that section. The link resolves the pm-graph project page in Intel's Open Ecosystem area at intel.com. Update this webpage entry. M: "Todd E Brandt" L: linux...@vger.kernel.org Signed-off-by: Lukas Bulwahn --- MAINTAINERS | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1333928a7be4..99adcd74b06a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6747,7 +6747,6 @@ M:Maarten Lankhorst M: Maxime Ripard M: Thomas Zimmermann S: Maintained -W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/gpu/ F: drivers/gpu/drm/* @@ -10250,7 +10249,7 @@ M: Rodrigo Vivi M: Tvrtko Ursulin L: intel-gfx@lists.freedesktop.org S: Supported -W: https://01.org/linuxgraphics/ +W: https://www.intel.com/content/www/us/en/develop/documentation/intel-graphics-for-linux-programmers-reference-guide/top.html Q: http://patchwork.freedesktop.org/project/intel-gfx/ B: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs C: irc://irc.oftc.net/intel-gfx @@ -10312,7 +10311,6 @@ M: Zhi Wang L: intel-gvt-...@lists.freedesktop.org L: intel-gfx@lists.freedesktop.org S: Supported -W: https://01.org/igvt-g T: git https://github.com/intel/gvt-linux.git F: drivers/gpu/drm/i915/gvt/ @@ -16668,7 +1,7 @@ PM-GRAPH UTILITY M: "Todd E Brandt" L: linux...@vger.kernel.org S: Supported -W: https://01.org/pm-graph +W: https://www.intel.com/content/www/us/en/developer/topic-technology/open/pm-graph/overview.html B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph&product=Tools T: git git://github.com/intel/pm-graph F: tools/power/pm-graph -- 2.17.1
[Intel-gfx] [PATCH] drm/dp_helper: tweak kerneldoc to address warning
Commit 07c9b8634fb6 ("drm/dp_helper: Add helpers to configure PCONs
RGB-YCbCr Conversion") introduces a warning with make htmldocs in
./drivers/gpu/drm/drm_dp_helper.c:965 for
drm_dp_downstream_rgb_to_ycbcr_conversion():
warning: Excess function parameter 'colorspc' description
warning: Function parameter or member 'color_spc' not described
Tweak the kerneldoc for drm_dp_downstream_rgb_to_ycbcr_conversion().
Fixes: 07c9b8634fb6 ("drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr
Conversion")
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210115
Jani, please pick this minor doc warning fixup.
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..d60e94ac6fdd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -954,7 +954,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
* RGB->YCbCr conversion
capability
* @dpcd: DisplayPort configuration data
* @port_cap: downstream facing port capabilities
- * @colorspc: Colorspace for which conversion cap is sought
+ * @color_spc: Colorspace for which conversion cap is sought
*
* Returns: whether the downstream facing port can convert RGB->YCbCr for a
given
* colorspace.
@@ -3134,7 +3134,7 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux
*aux, u8 pps_param[6])
}
EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
-/*
+/**
* drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to
Ycbcr
* @aux: displayPort AUX channel
* @color_spc: Color-space/s for which conversion is to be enabled, 0 for
disable.
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot
On Mon, Nov 23, 2020 at 4:52 PM Jani Nikula wrote:
>
> On Sat, 21 Nov 2020, James Bottomley
> wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> >> A difficult part of automating commits is composing the subsystem
> >> preamble in the commit log. For the ongoing effort of a fixer
> >> producing
> >> one or two fixes a release the use of 'treewide:' does not seem
> >> appropriate.
> >>
> >> It would be better if the normal prefix was used. Unfortunately
> >> normal is
> >> not consistent across the tree.
> >>
> >>
> >> D: Commit subsystem prefix
> >>
> >> ex/ for FPGA DFL DRIVERS
> >>
> >> D: fpga: dfl:
> >>
> >
> > I've got to bet this is going to cause more issues than it solves.
>
> Agreed.
>
Tom, this a problem only kernel janitors encounter; all other
developers really do not have that issue. The time spent on creating
the patch is much larger than the amount saved if the commit log
header line prefix would be derived automatically. I believe Julia
Lawall, Arnd Bergmann and Nathan Chancellor as long-term
high-frequency janitors do have already scripted approaches to that
issue. Maybe they simply need to share these scripts with you and you
consolidate them and share with everyone?
Also, making clean-up patches cumbersome has a positive side as well;
maintainers are not swamped with fully automated patch submissions.
There have been some bad experiences with some submitters on that in
the past...
> > SCSI uses scsi: : for drivers but not every driver has a
> > MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer
> > things, but we're not consistent. Block uses blk-: for all
> > of it's stuff but almost no s have a MAINTAINERS entry. So
> > the next thing you're going to cause is an explosion of suggested
> > MAINTAINERs entries.
>
> On the one hand, adoption of new MAINTAINERS entries has been really
> slow. Look at B, C, or P, for instance. On the other hand, if this were
> to get adopted, you'll potentially get conflicting prefixes for patches
> touching multiple files. Then what?
>
> I'm guessing a script looking at git log could come up with better
> suggestions for prefixes via popularity contest than manually maintained
> MAINTAINERS entries. It might not always get it right, but then human
> outsiders aren't going to always get it right either.
>
> Now you'll only need Someone(tm) to write the script. ;)
>
> Something quick like this:
>
> git log --since={1year} --pretty=format:%s -- |\
> grep -v "^\(Merge\|Revert\)" |\
> sed 's/:[^:]*$//' |\
> sort | uniq -c | sort -rn | head -5
>
> already gives me results that really aren't worse than some of the
> prefixes invented by drive-by contributors.
>
I agree I do not see the need to introduce something in MAINTAINERS;
from my observations maintaining MAINTAINERS, there is sufficient work
on adoption and maintenance of the existing entries already without
such an yet another additional entry. Some entries are outdated or
wrong and the janitor task of cleaning those up is already enough work
for involved janitors and enough churn for involved maintainers. So a
machine-learned approach as above is probably good enough, but if you
think you need more complex rules try to learn them from the data at
hand... certainly a nice task to do with machine learning on commit
message prefixes.
Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf.rst: repair length of title underline
With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are
a bad idea"), document generation warns:
Documentation/driver-api/dma-buf.rst:182: \
WARNING: Title underline too short.
Repair length of title underline to remove warning.
Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad
idea")
Signed-off-by: Lukas Bulwahn
---
Daniel, please pick this minor non-urgent fix to your new documentation.
Documentation/driver-api/dma-buf.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 100bfd227265..13ea0cc0a3fa 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -179,7 +179,7 @@ DMA Fence uABI/Sync File
:internal:
Indefinite DMA Fences
-
+~
At various times &dma_fence with an indefinite time until dma_fence_wait()
finishes have been proposed. Examples include:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] MAINTAINERS: adjust to reservation.h renaming
Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
renamed include/linux/reservation.h to include/linux/dma-resv.h, but
missed the reference in the MAINTAINERS entry.
Since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches F: include/linux/reservation.h
Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
Co-developed-by: Sebastian Duda
Signed-off-by: Sebastian Duda
Signed-off-by: Lukas Bulwahn
---
Christian, please pick this patch.
applies cleanly on current master and next-20200303
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6158a143a13e..3d6cb2789c9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5022,7 +5022,7 @@ L:dri-de...@lists.freedesktop.org
L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
F: drivers/dma-buf/
F: include/linux/dma-buf*
-F: include/linux/reservation.h
+F: include/linux/dma-resv.h
F: include/linux/*fence.h
F: Documentation/driver-api/dma-buf.rst
K: dma_(buf|fence|resv)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481
On Fri, 2 Feb 2018, Jani Nikula wrote: > Being brutally honest, please write shorter reports and shorter emails > to the lists. > > The static analysis reports are welcome, but only when 1) we didn't > already fix it in linux-next, or 2) it reveals an actual bug, not just a > warning, warranting a backport. That will be our policy. Lukas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481
Hi Greg, On Thu, 1 Feb 2018, Greg KH wrote: > On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: > > Dear Rodrigo Vivi, Ville Syrjälä, > > > > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We > > intend to use static analysis tools on the kernel source to identify, > > analyze and report issues. As a very first step, we are looking into > > clang compiler warnings and will then move to more sophisticated tools. > > > > [...] > > > > Linux 4.15 is shipped with this clang warning, but we don't see the > > crucial need to provide a backport commit to the stable branch for 4.15. > > We just wanted to inform you about our analysis of this clang warning. > > Ultimately the final call if you would like to address this clang warning > > in 4.15 is yours. > > Note, I have not taken "clang warning fixes" for stable kernel updates > in the past, and I doubt I will in the future, unless the tree "builds > clean" with clang. If it eventually gets there, then yes, I will do > that. > > Note, if you are going to email this out to everyone who fixes a warning > message, you might want to reconsider it. That's going to be a lot of > work, and for people who have already fixed an issue, it's kind of > pointless to just remind them of work they have done in the past, right? > > What is the goal of these types of emails? > We are interested in providing useful information on potential bugs or bug patterns that we get from static analysis tools, after we pre-assess them and manually select them to send to the review process of the patch submission. For me, the clang warnings were an easy starting point for a student to set up and look at, compared to much more sophisticated tools, such as coccinelle, sparse or new tools for the kernel development, such as CMBC or facebook's Infer. Once we really understand which tools are useful and which information can be quickly pre-assessed and sent out in a useful way without just creating more noise in the discussion, I would have contacted the 0-day infrastructure team or the kernelci.org team to continue the discussion how to include our first setup into a proper semi-automated service. Using the clang warnings, I wanted to explore how this would even potentially work. Considering clang, of course, currently, we cannot compile the whole kernel with all possible kernel configurations with clang, but I believe Nick Desaulniers, Matthias Kaehlcke and others are already working on that and are getting close to this goal. Hence, assuming they will be successful soon, I wanted to explore the next step of using static analysis tools around the clang/LLVM compiler. Actually, v4.15 builds almost "cleanly" with clang: For defconfig, there are only two clang compiler warnings and the one that we looked into deeper here is already resolved in linux-next, so chances are actually high that we might get to this "builds clean" soon-ish, at least for defconfig. Concerning clang warnings and how to progress towards that goal of building cleanly, my strategy is to identify when new clang compiler warnings are introduced and just point these warnings out as code smells during the review discussion before they are merged into the first maintainer tree. If we manually inspect these clang warnings to make sure that they are genuine code smells of some "imprecise implementation" before we send them to the mailing list, I would hope that they are of some value for the developer in the submission process and he/she could address the warning in a patch v2 while he/she is reacting to the other review comments from the human reviewers. At best, I always considered them as useful information during the review process, but I certainly DO NOT want to start patching the kernel due to clang warnings. The chances/risk that we just break more due to naively fixing warnings without proper understanding is much higher than the benefit of actually improving the situation. If I recall correctly, I think this is also one of the lessons learned from motivating newcomers to address warnings in previous kernel newbies activities. Greg, do you think it is worthwhile to invest some effort to move towards the goal "kernel builds cleanly with clang"? Would you agree that providing information during the patch review is a good way to move forward to this goal if we find a suitable manner to provide this feedback quickly and cleanly at this very early stage of development? If not, we will immediately stop to move in this direction and this is the first and last email that you have seen of this kind, and we will have to come up with better/other ideas around work on the Linux kernel. If so, we will continue in the direction sketc
