linux configs: cleanup

[MilhouseVH]

I've run make oldconfig on all projects and accepted the defaults.

These are the differences:

1. All projects: Enable NFS and CIFS kernel file caching, with SMB2 and (when available) SMB3 support
2. x86: Enable additional options (PERF_EVENTS_AMD_POWER, SND_DRIVERS, DRM_DP_AUX_CHARDEV, I2C_DESIGNWARE_BAYTRAIL)
3. x86: Drop MEMSTICK support, enable MMC_SDHCI_PLTFM
4. x86 & WeTek_Play: Enable CONFIG_RESET_CONTROLLER (sync with other projects)
5. WeTek_Core: Fix CONFIG_CPU_FREQ_DEFAULT_GOV_HOTPLUG typo
6. Several projects are missing CONFIG_FB_MODE_HELPERS=y which is selected by CONFIG_FB_UDL in config: ADD CONFIG_FB_UDL module (USB displaylink) #1087
7. Drop any other other obsolete options (eg. CONFIG_INITRAMFS_ROOT_UID etc.)

Would be good if all project maintainers could take a look and comment if they have any concerns.

I'll include these changes in RPi/RPi2/Generic test builds - if no issues/concerns, merge in a week or so?

[stefansaraev]

wy would amlogic hardware need CONFIG_FB_MODE_HELPERS ?

[MilhouseVH]

As mentioned, because of #1087 - CONFIG_FB_MODE_HELPERS=y is now a default.

(Perhaps the question is why has CONFIG_FB_UDL been enabled for amlogic?)

[stefansaraev]

yep. I doubt CONFIG_FB_UDL works or has any use case on amlogic.

EDIT: I dont think it works on rpi either, but well.. however

[MilhouseVH]

OK I'll remove it from WeTek_* and update. Thanks.

[MilhouseVH]

Updated.

[MilhouseVH]

EDIT: I dont think it works on rpi either, but well.. however

Not sure about that, as it remains enabled upstream:

https://github.com/raspberrypi/linux/blob/64845d8fcca13b82762e2637228a3f32f6f41420/arch/arm/configs/bcm2709_defconfig#L842
https://github.com/raspberrypi/linux/blob/64845d8fcca13b82762e2637228a3f32f6f41420/arch/arm/configs/bcmrpi_defconfig#L835

Ping @popcornmix

[popcornmix]

I believe CONFIG_FB_UDL does work for console framebuffer on pi, but not for firmware driven openGL ES. So I don't believe anyone would car if removed for LE.

[piotrasd]

i dont know why for RPI they this enabled

but that was here #1087
display link working from USB 3.0 in my knowledge ...

[popcornmix]

@nahun are you actually using USB display link display with LE on Pi?

[piotrasd]

i just got USB-C adapter to HDMI but i got error

[ 4341.650172] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
[ 4341.650177] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
[ 4341.650179] pcieport 0000:00:1c.0: device [8086:9d10] error status/mask=00000001/00002000
[ 4341.650180] pcieport 0000:00:1c.0: [ 0] Receiver Error (First)

i will check if some other config kernel changes are needed

[stefansaraev]

the stupid thing only makes sense on x86 with drm/x11 and good usb3 usb controller. just remove it.

[nahun]

No I couldn't get it to work, definitely can be removed.

[piotrasd]

i tested again on cold boot with connected USB-C adapter and boots fine with picture on screen :)
so for x86 please leave that.

"[ 54.417539] [drm:intel_dp_read_desc] DP branch: OUI 00-1c-f8 dev-ID 171GB0 HW-rev 0.1 SW-rev 15.29"

[MilhouseVH]

Updated with additional commit dropping FB_UDL from RPi/RPi2/Odroid_C2/imx6.

CONFIG_FB_MODE_HELPERS=y remains in imx6/4.4-xbian config as it is selected by CONFIG_FB_MXC=y.

This leaves FB_UDL enabled only for Generic.

@piotrasd you commented on #1087:

for generic please enable also DRM_UDL=m ;)

that change wthout DRM for UDL dont will works on Generic, im tested once DisplayLink - USB3.0 to HDMI cable/adapter and worked with DRM_UDL=m/y, otherwise is no point to merge that for rest project if not will work

Is DRM_UDL=m still required for FB_UDL to work on Generic? Currently DRM_UDL is not set, do you have it enabled in your build?

[piotrasd]

i will confirm by check official Generic build

[piotrasd]

after test on latest official LE 8.0.1 where "DRM_UDL is not set" - USB-C to HDMI adapter working ;)

[MilhouseVH]

Rebased after #1533.