[PATCH] Enable VIDEO_GO7007 as module
by Nicolas Chauvet
This driver can be used in some usb encoder devices.
http://www.linuxtv.org/wiki/index.php/Go7007
The related firmware files are in linux-firmware for some time.
The driver has left staging since few release, but I'm
fine if this is enabled in linux kernel 4.5 and later.
---
config-generic | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/config-generic b/config-generic
index 9eef876..1cfcfab 100644
--- a/config-generic
+++ b/config-generic
@@ -3410,6 +3410,10 @@ CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_CX231XX_RC=y
+CONFIG_VIDEO_GO7007=m
+CONFIG_VIDEO_GO7007_USB=m
+CONFIG_VIDEO_GO7007_LOADER=m
+CONFIG_VIDEO_GO7007_USB_S2250_BOARD=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_IVTV=m
@@ -3422,6 +3426,7 @@ CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_DVB=m
+CONFIG_VIDEO_SAA7134_GO7007=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SOLO6X10=m
CONFIG_VIDEO_USBVISION=m
@@ -5560,7 +5565,6 @@ CONFIG_STAGING_MEDIA=y
# CONFIG_VIDEO_DT3155 is not set
# CONFIG_TI_ST is not set
# CONFIG_FB_XGI is not set
-# CONFIG_VIDEO_GO7007 is not set
# CONFIG_I2C_BCM2048 is not set
# CONFIG_DT3155 is not set
# CONFIG_PRISM2_USB is not set
--
1.7.2.1
7 years, 3 months
Re: our chat in #fedora-kernel
by Josh Boyer
On Sun, Feb 28, 2016 at 12:24 PM, Corey Sheldon <sheldon.corey(a)gmail.com> wrote:
> Josh,
>
Adding the Fedora kernel list on CC.
> Been updating my blog with news of the respins Southern_Gentlemen
> (fas: jbwillia) makes when new kernels make it to updates, like
> 4.4.2-301 did last night.
>
>
> Both for personal knowledge and per requests for a more 'snapshot'-ish
> changelog I am looking to get a effective .diff changelog since the
> last kernel.
"The last kernel" is kind of the weird part here. For Fedora, that
can mean anything between simply another build of the existing major
version with a minor fix included, to a whole kernel version rebase.
We'll try and cover all the cases, but as usual the answer is never
the same or any particular kernel.
> As I understand the work flow being:
>
> old kernel foo has features / fixes /etc
>
>
>
> new kernel bar
>
> since last re-spin with kernel foo this re-spin has updates from
> %date and the following fixes / patches which I presume would have ofc
> those in rpm -qp --changelog %bar.src.rpm.
Correct.
> However is there a place I could link to or parse for a more thorough
> %changelog ? without having to parse the entire creation spec file and /
> or hoping it has build version marked in the spec file?
The spec file doesn't have what you're looking for. The changelog in
the spec file is the only place we log any kind of description and
it's kept intentionally terse.
Now, if you can determine the old and new versions then there are a
few things you can do. I'll give some examples.
For things like kernel-4.3.6 -> 4.4.2, that would be a major version
rebase. As Laura said in the channel yesterday, the kernelnewbies.org
site usually has a decent writeup of features and major fixes for each
major kernel version. You can find the latest at the site Laura
linked to, or all their writeups at
http://kernelnewbies.org/LinuxVersions.
For things like kernel-4.4.2-300 -> 4.4.2-301, the changelog is going
to have a list of the stuff that is specifically interesting to
Fedora. That is simply a build of the existing upstream kernel, with
some changes we've added.
For a bump like 4.4.2 -> 4.4.3, there really isn't a good answer.
That is an upstream stable kernel release. There are bugfixes all
over the kernel tree, sometimes numbering in the hundreds of commits.
There may be some bug numbers listed in the RPM changelog that an
upstream stable release fixes, and we'll note that in the RPM
changelog if so. For the most part though, this is simply "more
fixes".
I hope that helps. If you have any further questions, please let us know.
josh
7 years, 3 months
[PATCH] Fix boot on jetson-tk1 related to platform_nouveau
by Nicolas Chauvet
Patch is reported at
http://marc.info/?l=linux-tegra&m=145633528825832&w=2
This will fix boot on kernel 4.3+ as experienced with
fedora kernel 4.3.5
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c29f7cc0
[00000000] *pgd=00000000
Internal error: Oops: 205 [#1] SMP ARM
Modules linked in: gpio_keys(+) phy_tegra_usb(+) ahci_tegra libahci_platform nouveau(+) rtc_tegra i2c_algo_bit i2c_tegra tegra_drm ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm host1x mmc_block sdhci_tegra sdhci_pltfm sdhci mmc_core
CPU: 2 PID: 318 Comm: systemd-udevd Not tainted 4.4.2-300.fc23.armv7hl+lpae #1
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
task: edc67500 ti: c28ae000 task.ti: c28ae000
PC is at __list_del_entry+0x40/0x94
LR is at list_del+0xc/0x1c
pc : [<c035b498>] lr : [<c035b4f8>] psr: 80010013
sp : c28afd08 ip : 00000020 fp : c28aff58
r10: c242d488 r9 : 0000001b r8 : c0b4d528
r7 : c28afd6c r6 : ffffffff r5 : c28afd6c r4 : c288b02c
r3 : c288b02c r2 : 00000000 r1 : 00000000 r0 : c288b02c
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 30c5387d Table: 829f7cc0 DAC: 55555555
Process systemd-udevd (pid: 318, stack limit = 0xc28ae220)
---
drm-nouveau-platform-fix_deferred_probe.patch | 114 +++++++++++++++++++++++++
kernel.spec | 3 +
2 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 drm-nouveau-platform-fix_deferred_probe.patch
diff --git a/drm-nouveau-platform-fix_deferred_probe.patch b/drm-nouveau-platform-fix_deferred_probe.patch
new file mode 100644
index 0000000..36aeb91
--- /dev/null
+++ b/drm-nouveau-platform-fix_deferred_probe.patch
@@ -0,0 +1,114 @@
+From: Thierry Reding <thierry.reding(a)gmail.com>
+To: Ben Skeggs <bskeggs(a)redhat.com>
+Cc: Alexandre Courbot <gnurou(a)gmail.com>,
+ Nicolas Chauvet <kwizart(a)gmail.com>,
+ dri-devel(a)lists.freedesktop.org,
+ linux-tegra(a)vger.kernel.org
+Subject: [PATCH] drm/nouveau: platform: Fix deferred probe
+Date: Wed, 24 Feb 2016 18:34:43 +0100
+Message-Id: <1456335283-22097-1-git-send-email-thierry.reding(a)gmail.com>
+X-Mailer: git-send-email 2.7.1
+
+From: Thierry Reding <treding(a)nvidia.com>
+
+The error cleanup paths aren't quite correct and will crash upon
+deferred probe.
+
+Cc: stable(a)vger.kernel.org # v4.3+
+Signed-off-by: Thierry Reding <treding(a)nvidia.com>
+---
+ drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +-
+ drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 40 ++++++++++++++++------
+ 2 files changed, 30 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c b/drivers/gpu/drm/nouveau/nouveau_platform.c
+index 8a70cec59bcd..2dfe58af12e4 100644
+--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
++++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
+@@ -24,7 +24,7 @@
+ static int nouveau_platform_probe(struct platform_device *pdev)
+ {
+ const struct nvkm_device_tegra_func *func;
+- struct nvkm_device *device;
++ struct nvkm_device *device = NULL;
+ struct drm_device *drm;
+ int ret;
+
+diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+index 7f8a42721eb2..e7e581d6a8ff 100644
+--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
++++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+@@ -252,32 +252,40 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func,
+
+ if (!(tdev = kzalloc(sizeof(*tdev), GFP_KERNEL)))
+ return -ENOMEM;
+- *pdevice = &tdev->device;
++
+ tdev->func = func;
+ tdev->pdev = pdev;
+ tdev->irq = -1;
+
+ tdev->vdd = devm_regulator_get(&pdev->dev, "vdd");
+- if (IS_ERR(tdev->vdd))
+- return PTR_ERR(tdev->vdd);
++ if (IS_ERR(tdev->vdd)) {
++ ret = PTR_ERR(tdev->vdd);
++ goto free;
++ }
+
+ tdev->rst = devm_reset_control_get(&pdev->dev, "gpu");
+- if (IS_ERR(tdev->rst))
+- return PTR_ERR(tdev->rst);
++ if (IS_ERR(tdev->rst)) {
++ ret = PTR_ERR(tdev->rst);
++ goto free;
++ }
+
+ tdev->clk = devm_clk_get(&pdev->dev, "gpu");
+- if (IS_ERR(tdev->clk))
+- return PTR_ERR(tdev->clk);
++ if (IS_ERR(tdev->clk)) {
++ ret = PTR_ERR(tdev->clk);
++ goto free;
++ }
+
+ tdev->clk_pwr = devm_clk_get(&pdev->dev, "pwr");
+- if (IS_ERR(tdev->clk_pwr))
+- return PTR_ERR(tdev->clk_pwr);
++ if (IS_ERR(tdev->clk_pwr)) {
++ ret = PTR_ERR(tdev->clk_pwr);
++ goto free;
++ }
+
+ nvkm_device_tegra_probe_iommu(tdev);
+
+ ret = nvkm_device_tegra_power_up(tdev);
+ if (ret)
+- return ret;
++ goto remove;
+
+ tdev->gpu_speedo = tegra_sku_info.gpu_speedo_value;
+ ret = nvkm_device_ctor(&nvkm_device_tegra_func, NULL, &pdev->dev,
+@@ -285,9 +293,19 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func,
+ cfg, dbg, detect, mmio, subdev_mask,
+ &tdev->device);
+ if (ret)
+- return ret;
++ goto powerdown;
++
++ *pdevice = &tdev->device;
+
+ return 0;
++
++powerdown:
++ nvkm_device_tegra_power_down(tdev);
++remove:
++ nvkm_device_tegra_remove_iommu(tdev);
++free:
++ kfree(tdev);
++ return ret;
+ }
+ #else
+ int
+--
+2.7.1
diff --git a/kernel.spec b/kernel.spec
index a5a6997..edbb653 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -604,6 +604,9 @@ Patch646: HID-sony-do-not-bail-out-when-the-sixaxis-refuses-th.patch
#rhbz 1288684
Patch647: 0001-vsock-Fix-blocking-ops-call-in-prepare_to_wait.patch
+# Fix nouveau on arm for 4.3+
+Patch658: drm-nouveau-platform-fix_deferred_probe.patch
+
# END OF PATCH DEFINITIONS
%endif
--
1.7.2.1
7 years, 3 months
Re: 4.4 rebase coming to F23 soon
by Xose Vazquez Perez
Jóhann_B._Guðmundsson wrote:
> Arguably the regression in 4.4 with drm/i915 that causes screen
> flickering in dual monitor setups needs to be looked at before this gets
> released since it will get tiresome quite quickly for end users trying
> to do some work when suddenly one of the screen turns itself off and
> then on again.
I don't see any related patch in Greg's stable-queue for 4.4:
https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree...
PD: the performance of HyperKitty is really awful!
7 years, 3 months
4.4 rebase coming to F23 soon
by Laura Abbott
Hi,
4.4.2 is currently building and should be in updates-testing soon. As usual,
please test and give karma appropriately (negative karma for new issues,
not existing issues).
Thanks,
Laura
7 years, 3 months
conntrack: generic helper won't handle protocol 132. Please consider
loading the specific helper module.
by Reindl Harald
i see such messages in dmesg repeatly on several machines
most likely some form of attacks since it affects in random intervals
any machine with a public IP and seems to be pretty new at all
why is there no source IP logged?
[501585.285984] conntrack: generic helper won't handle protocol 132.
Please consider loading the specific helper module.
sctp 132 SCTP # Stream Control Transmission Protocol
7 years, 3 months
[PATCH] Add kernel-cross-headers subpackage
by Josh Boyer
The kernel-headers package it primarily used in Fedora to build the
toolchain components. This works fine for native builds, but we do
not have cross-architecture headers available. That means that the
cross compiler toolchains we have can only be built without headers
and therefore are only useful for building the kernel. Given that
Fedora does not allow cross-compiling of it's packages, that hasn't
been a problem to date.
However, the toolchains might be used by application developers to
build their own software. Providing the ability to build cross
toolchains that offer glibc as well may benefit these users. This
provides a kernel-cross-headers package that will at least allow
this possibility.
---
kernel.spec | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/kernel.spec b/kernel.spec
index 5578b2c..5253426 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -90,6 +90,7 @@ Summary: The Linux kernel
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
+%define with_cross_headers %{?_without_cross_headers: 0} %{?!_without_cross_headers: 1}
# perf
%define with_perf %{?_without_perf: 0} %{?!_without_perf: 1}
# tools
@@ -227,6 +228,7 @@ Summary: The Linux kernel
%ifarch noarch
%define with_up 0
%define with_headers 0
+%define with_cross_headers 0
%define with_tools 0
%define with_perf 0
%define all_arch_configs kernel-%{version}-*.config
@@ -291,6 +293,7 @@ Summary: The Linux kernel
# just like we used to only build them on i386 for x86
%ifnarch armv7hl
%define with_headers 0
+%define with_cross_headers 0
%define with_perf 0
%define with_tools 0
%endif
@@ -649,6 +652,17 @@ header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
glibc package.
+%package cross-headers
+Summary: Header files for the Linux kernel for use by cross-glibc
+Group: Development/System
+%description cross-headers
+Kernel-cross-headers includes the C header files that specify the interface
+between the Linux kernel and userspace libraries and programs. The
+header files define structures and constants that are needed for
+building most standard programs and are also needed for rebuilding the
+cross-glibc package.
+
+
%package bootwrapper
Summary: Boot wrapper files for generating combined kernel + initrd images
Group: Development/System
@@ -1738,6 +1752,33 @@ find $RPM_BUILD_ROOT/usr/include \
%endif
+%if %{with_cross_headers}
+mkdir -p $RPM_BUILD_ROOT/usr/tmp-headers
+make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr/tmp-headers headers_install_all
+
+find $RPM_BUILD_ROOT/usr/tmp-headers/include \
+ \( -name .install -o -name .check -o \
+ -name ..install.cmd -o -name ..check.cmd \) | xargs rm -f
+
+# Copy all the architectures we care about to their respective asm directories
+for arch in arm arm64 powerpc s390 x86 ; do
+mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include
+mv $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-${arch} $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/asm
+cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/.
+done
+
+# Remove the rest of the architectures
+rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/arch*
+rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-*
+
+# Copy the rest of the headers over
+for arch in arm arm64 powerpc s390 x86 ; do
+cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/.
+done
+
+rm -rf $RPM_BUILD_ROOT/usr/tmp-headers
+%endif
+
%if %{with_perf}
# perf tool binary and supporting scripts/binaries
%{perf_make} DESTDIR=$RPM_BUILD_ROOT lib=%{_lib} install-bin install-traceevent-plugins
@@ -1924,6 +1965,12 @@ fi
/usr/include/*
%endif
+%if %{with_cross_headers}
+%files cross-headers
+%defattr(-,root,root)
+/usr/*-linux-gnu/include/*
+%endif
+
%if %{with_bootwrapper}
%files bootwrapper
%defattr(-,root,root)
--
2.5.0
7 years, 3 months
build regression from c153693: Simplify module TOC handling
by Peter Robinson
Hi Alan,
Your patch for "powerpc: Simplify module TOC handling" is causing the
Fedora ppc64le to fail to build with depmod failures. Reverting the
commit fixes it for us on rawhide.
We're getting the out put below, full logs at [1]. Let me know if you
have any other queries.
Regards,
Peter
[1] http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/5115/3125115/build...
+ depmod -b . -aeF ./System.map 4.5.0-0.rc2.git0.1.fc24.ppc64le
Depmod failure
+ '[' -s depmod.out ']'
+ echo 'Depmod failure'
+ cat depmod.out
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/powernv/opal-prd.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/pseries/pseries_energy.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/pseries/hvcserver.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm-pr.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm-hv.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/rcu/rcutorture.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/trace/ring_buffer_benchmark.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/torture.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/fs/nfs_common/nfs_acl.ko
needs unknown symbol .TOC.
depmod: WARNING:
/builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/fs/nfs_common/grace.ko
needs unknown symbol .TOC.
7 years, 3 months
