Re: [GIT PULL for v5.8-rc1] media updates
The pull request you sent on Sat, 13 Jun 2020 01:26:15 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > tags/media/v5.8-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ac911b316336ad3d22b09e82698f0463347a5507 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[GIT PULL for v5.8-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.8-2 For: - some fixes for Kernel 5.8; - a set of atomisp patches. They remove several abstraction layers, and fixes clang and gcc warnings (that were hidden via some macros that were disabling 4 or 5 types of warnings there). There are also some important fixes and sensor auto-detection on newer BIOSes via ACPI _DCM tables. Thanks! Mauro - The following changes since commit 938b29db3aa9c293c7c1366b16e55e308f1a1ddd: media: Documentation: media: Refer to mbus format documentation from CSI-2 docs (2020-05-25 15:47:02 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.8-2 for you to fetch changes up to 2630e1bb0948c3134c6f22ad275ae27cc6023532: media: rkvdec: Fix H264 scaling list order (2020-06-11 19:21:38 +0200) media updates for v5.8-rc1 Arnd Bergmann (5): media: staging: media: atomisp: declare 'struct device' before using it media: staging: media: atomisp: fix enum type mixups media: staging: media: atomisp: disable all custom formats media: staging: media: atomisp: add PMIC_OPREGION dependency media: staging: media: atomisp: fix stack overflow in init_pipe_defaults() Colin Ian King (1): media: atomisp: fix a handful of spelling mistakes Geert Uytterhoeven (1): media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORT Jernej Skrabec (1): media: cedrus: Implement runtime PM Jonas Karlman (2): media: v4l2-ctrls: Unset correct HEVC loop filter flag media: rkvdec: Fix H264 scaling list order Marek Szyprowski (1): media: s5p-mfc: Properly handle dma_parms for the allocated devices Mauro Carvalho Chehab (71): media: atomisp: fix pipeline initialization code media: atomisp: get rid of hmm_vm.c media: atomisp: reduce debug printk rate when IRQs are received media: atomisp: avoid a copy of v4l2_mbus_framefmt at stack media: atomisp: improve debug messages for set format media: atomisp: don't flood dmesg with -EAGAIN return codes media: atomisp: update TODO list media: atomisp: get rid of some old broken debug code media: atomisp: make it use dbg_level to control debug level media: atomisp: partially get rid of one abstraction layer media: atomisp: drop a cast for a const argument media: atomisp: fix size of delay_frames array media: atomisp: simplify hive_isp_css_mm_hrt wrapper media: atomisp: get rid of the hrt/hive_isp_css_mm_hrt abstraction layer media: atomisp: reduce abstraction at ia_css_memory_access media: atomisp: go one step further to drop ia_css_memory_access.c media: atomisp: get rid of mmgr_load and mmgr_store media: atomisp: get rid of unused memory_realloc code media: atomisp: change the type returned by mmgr alloc media: atomisp: get rid of memory_access.c media: atomisp: hmm_bo: untag user pointers media: atomisp: add debug message to help debugging hmm code media: atomisp: use Yocto Aero default hmm pool sizes media: atomisp: fix driver caps media: atomisp: use pin_user_pages() for memory allocation media: atomisp: add debug for hmm alloc media: atomisp: improve warning for IRQ enable function media: atomisp: add debug functions for received events media: atomisp: add more comments about frame allocation media: atomisp: remove kvmalloc/kvcalloc abstractions media: atomisp: avoid OOPS due to non-existing ref_frames media: atomisp: avoid an extra memset() when alloc memory media: atomisp: remove some trivial wrappers from compat css20 media: atomisp: do another round of coding style cleanup media: atomisp: get rid of non-Linux error codes media: atomisp: get rid of an error abstraction layer media: atomisp: don't cause a warn if probe failed media: atomisp: get rid of a bunch of other wrappers media: atomisp: get rid of system_types.h media: atomisp: provide more details about the firmware binaries media: atomisp: print firmware data during load media: atomisp: allow passing firmware name at modprobe time media: atomisp: add a debug message at hmm free media: atomisp: add some debug messages when binaries are used media: atomisp: add SPDX headers media: atomisp: remove format duplication at mbus->fourcc table media: atomisp: re-enable warnings again media: atomisp: get rid of sh_css_pipe.c media: atomisp: get rid of an unused IRQ duplicated event media: atomisp: get rid of a left-over wrapper function media: atomisp: comment an unused code media:
Re: [GIT PULL for v5.8-rc1] media updates
Em Wed, 3 Jun 2020 21:21:06 -0700 Linus Torvalds escreveu: > On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab > wrote: > > > > - The atomisp staging driver was resurrected. It is meant to work with > > 4 generations of cameras on Atom-based laptops, tablets and cell > > phones. So, it seems worth investing time to cleanup this driver and > > making it in good shape. > > Hmm. It causes a warning for me: > >drivers/staging/media/atomisp/pci/atomisp_v4l2.c:764:12: warning: > ‘atomisp_mrfld_power’ defined but not used [-Wunused-function] > > which is a bit annoying. > > I can see the FIXME's there, but the warning still isn't acceptable. > > I'll add a fixup commit. I was going to do it in the merge itself, but > decided that was a bit too subtle. OK! I have a patch like that already on a separate pile of patches, which address several other things. I opted to place them in separate, in order to give people some time to comment and review. My plan is to keep them on linux-next and submit you next week, if ok for you. The new series should drop all LLVM warnings and add SPDX headers, among other things. Thanks, Mauro
Re: [GIT PULL for v5.8-rc1] media updates
Em Wed, 3 Jun 2020 21:13:21 -0700
Linus Torvalds escreveu:
> On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab
> wrote:
> >
> > PS.: The diffstat is so big that I almost dropped it, as it is almost
> > useless for humans to read. I ended by not doing it just because perhaps
> > you could be using some sort of script to check diffstat.
>
> No, but I do compare the basics, and you don't have to more than scan
> it to see that "ok, it only touches area xyz".
Ok.
> And it turns out that it is huge for you partly because you have the
> default (fairly low) git rename detection limits, in order to avoid
> using a lot of CPU or memory for rename detection.
>
> So you get:
>
> > 2181 files changed, 260633 insertions(+), 106012 deletions(-)
>
> while I get
>
> 1698 files changed, 161922 insertions(+), 7301 deletions(-)
>
> which is a noticeable difference. Still a big diffstat, but quite a
> bit smaller than yours.
>
> You also get a _lot_ more noise in the form of "create mode xyz" and
> "delete mode abc" notices, while for me a lot of them are just "rename
> abc => xyz". So there's a double whammy for you.
>
> The reason is that your diff only has renames for the 100% matches like this:
>
> > rename Documentation/{media/v4l-drivers =>
> > admin-guide/media}/au0828-cardlist.rst (100%)
>
> which git can detect purely by seeing "oh, same exact SHA1".
>
> But you don't have any non-100% renames.
>
> In contrast, the diffstat I see also has the inexact renames like
>
> rename Documentation/{media/v4l-drivers =>
> admin-guide/media}/bttv-cardlist.rst (99%)
> rename Documentation/{media/v4l-drivers => admin-guide/media}/bttv.rst (79%)
>
> because I have done
>
>git config diff.renamelimit 0
>
> to make the rename detection limit be infinite (alternatively, just
> edit your ~/.gitconfig file manually - it's often easier than
> remembering what the "git config" syntax is).
>
> You want to see
>
> [diff]
> renamelimit = 0
>
> in your ~/.gitconfig file (or, alternatively, if you want the setting
> to be per-repo, in your .git/config file in your repository).
>
> The default git limits for "should I spend CPU time and memory on
> detecting inexact renames" are fairly low, because people use git on
> fairly low-end machines.
I'm using renamelimit = 0 on one of my trees (the one I'm using for
the ReST conversion), and I even use -M1 there when sending patches
to docs (as some of the conversions require lots of indentation
changes, for example, on files with lots of ascii artwork), but on
my merge tree, I was using some limit, as it is not common to have
this huge amount of changes.
> I bet your development machine isn't some kind of low-end toy, and
> rename detection is not _that_ expensive.
Probably not as nice as yours, but it is a comfortable machine,
with 32 GB RAM, an i7-8705G CPU and a fast SSD disk.
Changing it to unlimited limit costed almost nothing here:
real0m1,210s
user0m1,009s
sys 0m0,190s
I'll use this from now on. Thanks for the tip!
Thanks,
Mauro
Re: [GIT PULL for v5.8-rc1] media updates
The pull request you sent on Wed, 3 Jun 2020 10:05:59 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > tags/media/v5.8-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a98f670e41a99f53acb1fb33cee9c6abbb2e6f23 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL for v5.8-rc1] media updates
On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab wrote: > > - The atomisp staging driver was resurrected. It is meant to work with > 4 generations of cameras on Atom-based laptops, tablets and cell > phones. So, it seems worth investing time to cleanup this driver and > making it in good shape. Hmm. It causes a warning for me: drivers/staging/media/atomisp/pci/atomisp_v4l2.c:764:12: warning: ‘atomisp_mrfld_power’ defined but not used [-Wunused-function] which is a bit annoying. I can see the FIXME's there, but the warning still isn't acceptable. I'll add a fixup commit. I was going to do it in the merge itself, but decided that was a bit too subtle. Linus
Re: [GIT PULL for v5.8-rc1] media updates
On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab
wrote:
>
> PS.: The diffstat is so big that I almost dropped it, as it is almost
> useless for humans to read. I ended by not doing it just because perhaps
> you could be using some sort of script to check diffstat.
No, but I do compare the basics, and you don't have to more than scan
it to see that "ok, it only touches area xyz".
And it turns out that it is huge for you partly because you have the
default (fairly low) git rename detection limits, in order to avoid
using a lot of CPU or memory for rename detection.
So you get:
> 2181 files changed, 260633 insertions(+), 106012 deletions(-)
while I get
1698 files changed, 161922 insertions(+), 7301 deletions(-)
which is a noticeable difference. Still a big diffstat, but quite a
bit smaller than yours.
You also get a _lot_ more noise in the form of "create mode xyz" and
"delete mode abc" notices, while for me a lot of them are just "rename
abc => xyz". So there's a double whammy for you.
The reason is that your diff only has renames for the 100% matches like this:
> rename Documentation/{media/v4l-drivers =>
> admin-guide/media}/au0828-cardlist.rst (100%)
which git can detect purely by seeing "oh, same exact SHA1".
But you don't have any non-100% renames.
In contrast, the diffstat I see also has the inexact renames like
rename Documentation/{media/v4l-drivers =>
admin-guide/media}/bttv-cardlist.rst (99%)
rename Documentation/{media/v4l-drivers => admin-guide/media}/bttv.rst (79%)
because I have done
git config diff.renamelimit 0
to make the rename detection limit be infinite (alternatively, just
edit your ~/.gitconfig file manually - it's often easier than
remembering what the "git config" syntax is).
You want to see
[diff]
renamelimit = 0
in your ~/.gitconfig file (or, alternatively, if you want the setting
to be per-repo, in your .git/config file in your repository).
The default git limits for "should I spend CPU time and memory on
detecting inexact renames" are fairly low, because people use git on
fairly low-end machines.
I bet your development machine isn't some kind of low-end toy, and
rename detection is not _that_ expensive.
Linus
