Re: [PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256
Jian-Hong Pan 於 2021年2月26日 週五 上午10:05寫道：
>
> 於 2021年2月26日 週五 上午9:04寫道：
> >
> > From: Chris Chiu
> >
> > The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
> > both the headset mic and the internal mic. Introduce new fixup
> > to enable the jack sense and the headset mic. However, the internal
> > mic actually connects to Intel SST audio. It still needs Intel SST
> > support to make internal mic capture work.
> >
> > Signed-off-by: Chris Chiu
> > ---
> > v1 -> v2: remove unnecessary aamix fixup
> >
> > sound/pci/hda/patch_realtek.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 1927605f0f7e..4871507cd4bf 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -6406,6 +6406,7 @@ enum {
> > ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> > ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> > ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> > + ALC256_FIXUP_ACER_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> > },
> > + [ALC256_FIXUP_ACER_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_PINS,
> > + .v.pins = (const struct hda_pintbl[]) {
> > + { 0x19, 0x02a1113c }, /* use as headset mic,
> > without its own jack detect */
> > + { 0x1a, 0x90a1092f }, /* use as internal mic */
>
> Since NID 0x1a is an internal DMIC, should this connection type be 0h?
> Or, even the quirk of the internal DMIC is not needed for this case.
> Because, it is Intel SST DMIC that does not connect to Realtek HDA
> CODEC. (Not sure for this one)
>
> The quirk of NID 0x19 is okay for me.
After more discussion and test with Chris, found the NID 0x1a quirk is
still needed. Otherwise, the headset MIC 0x19 will not work any more.
So, I ack the version 2 patch.
Acked-by: Jian-Hong Pan
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
> > ALC299_FIXUP_PREDATOR_SPK),
> > SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
> > ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> > SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
> > ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> > + SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> > ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > --
> > 2.20.1
> >
Re: [PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256
於 2021年2月26日 週五 上午9:04寫道：
>
> From: Chris Chiu
>
> The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
> both the headset mic and the internal mic. Introduce new fixup
> to enable the jack sense and the headset mic. However, the internal
> mic actually connects to Intel SST audio. It still needs Intel SST
> support to make internal mic capture work.
>
> Signed-off-by: Chris Chiu
> ---
> v1 -> v2: remove unnecessary aamix fixup
>
> sound/pci/hda/patch_realtek.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 1927605f0f7e..4871507cd4bf 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -6406,6 +6406,7 @@ enum {
> ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> + ALC256_FIXUP_ACER_HEADSET_MIC,
> };
>
> static const struct hda_fixup alc269_fixups[] = {
> @@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> },
> + [ALC256_FIXUP_ACER_HEADSET_MIC] = {
> + .type = HDA_FIXUP_PINS,
> + .v.pins = (const struct hda_pintbl[]) {
> + { 0x19, 0x02a1113c }, /* use as headset mic, without
> its own jack detect */
> + { 0x1a, 0x90a1092f }, /* use as internal mic */
Since NID 0x1a is an internal DMIC, should this connection type be 0h?
Or, even the quirk of the internal DMIC is not needed for this case.
Because, it is Intel SST DMIC that does not connect to Realtek HDA
CODEC. (Not sure for this one)
The quirk of NID 0x19 is okay for me.
BR,
Jian-Hong Pan
> + { }
> + },
> + .chained = true,
> + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> + },
> };
>
> static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> @@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] =
> {
> SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
> ALC299_FIXUP_PREDATOR_SPK),
> SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
> ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
> ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> + SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
> ALC256_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> + SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
> ALC256_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> ALC233_FIXUP_ACER_HEADSET_MIC),
> SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> ALC255_FIXUP_ACER_HEADSET_MIC),
> --
> 2.20.1
>
[PATCH] ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256
ASUS B1400CEPE laptop's headset audio is not enabled until
ALC256_FIXUP_ASUS_HPE quirk is applied.
Here is the original pin node values:
0x12 0x4000
0x13 0x41f0
0x14 0x90170110
0x18 0x41f0
0x19 0x41f0
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x40461b45
0x1e 0x41f0
0x21 0x04211020
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ed5b6b894dc1..290645516313 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8006,6 +8006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x194e, "ASUS UX563FD", ALC294_FIXUP_ASUS_HPE),
+ SND_PCI_QUIRK(0x1043, 0x1982, "ASUS B1400CEPE", ALC256_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.30.0
Re: [PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices
Jiri Kosina 於 2021年1月7日 週四 下午5:23寫道： > > On Wed, 23 Dec 2020, Jian-Hong Pan wrote: > > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > > > This patch maps the event as KEY_RFKILL. > > I don't know how exactly does the report descriptor of that device look > like, but is this not doable from userspace via setkeycode() (udev/systemd > is shipping a lot of such mappings already -- see evdev/keyboard > definitions in hwdb). Thanks for your suggestion! I have tested the key with evtest. But it has no response from all inputs. Nor response from xev. So, I tried usb monitor to see what does it send: $ lsusb -d 04f2:1236 Bus 001 Device 002: ID 04f2:1236 Chicony Electronics Co., Ltd $ sudo modprobe usbmon $ sudo cat /sys/kernel/debug/usb/usbmon/1u 9145e0dea6c0 348311963 C Ii:1:002:1 0:8 8 = 9145e0dea6c0 348311996 S Ii:1:002:1 -115:8 8 < 9145e0deaf00 352852533 C Ii:1:002:2 0:4 2 = 1101 9145e0deaf00 352852547 S Ii:1:002:2 -115:4 3 < It sends 0x1101 for the hotkey. The same response from hid events: $ sudo cat /sys/kernel/debug/hid/0003\:04F2\:1236.0002/events report (size 2) (numbered) = 11 01 Then, I notice there is the RFKILL event listed on the "Chicony USB Receiver Wireless Radio Control" device: $ sudo evtest /dev/input/event8 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x4f2 product 0x1236 version 0x111 Input device name: "Chicony USB Receiver Wireless Radio Control" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 103 (KEY_UP) Event code 105 (KEY_LEFT) Event code 106 (KEY_RIGHT) Event code 108 (KEY_DOWN) Event code 116 (KEY_POWER) Event code 138 (KEY_HELP) Event code 139 (KEY_MENU) Event code 142 (KEY_SLEEP) Event code 143 (KEY_WAKEUP) Event code 148 (KEY_PROG1) Event code 174 (KEY_EXIT) Event code 227 (KEY_SWITCHVIDEOMODE) Event code 247 (KEY_RFKILL) Event code 314 (BTN_SELECT) Event code 315 (BTN_START) Event code 353 (KEY_SELECT) Event code 356 (KEY_POWER2) Event code 408 (KEY_RESTART) Event code 438 (KEY_CONTEXT_MENU) Event type 2 (EV_REL) Event code 9 (REL_MISC) Event type 3 (EV_ABS) ... Also, after debugging, I found its HID application ID is HID_GD_WIRELESS_RADIO_CTLS 0x0001000c [1]. Then, I searched HID_GD_WIRELESS_RADIO_CTLS in the kernel. I found HID_GD_RFKILL_BTN [2] is mapped in hid-input. However, this key press on the Chicony keyboard maps to nothing, nor HID_GD_RFKILL_BTN. Only have the HID report with raw data 0x11 0x00 as mentioned above. It is more like ignored by the kernel and it even has no scancode. That's why I try to map it as KEY_RFKILL in the driver. [1] https://elixir.bootlin.com/linux/v5.10/source/include/linux/hid.h#L181 [2] https://elixir.bootlin.com/linux/v5.10/source/drivers/hid/hid-input.c#L743 Regards, Jian-Hong Pan
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Pavel Machek 於 2020年12月25日 週五 上午3:06寫道： > > On Tue 2020-12-22 15:38:56, Jian-Hong Pan wrote: > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > Fun, how can airplane mode work on _wireless_ keyboard? :-). Hmm! It is a funny point for this USB wireless keyboard! But I guess this kind of combination (with the "desktop") will not be used on an airplane :) Jian-Hong Pan
[PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices
Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
"Wireless Radio Control" feature. For example, the wireless keyboard
[04f2:1236] shipped with ASUS all-in-one desktop.
After consulting Chicony for this hotkey, learned the device will send
with 0x11 as the report ID and 0x1 as the value when the key is pressed
down.
This patch maps the event as KEY_RFKILL.
Signed-off-by: Jian-Hong Pan
---
v2: Remove the duplicated key pressed check.
drivers/hid/hid-chicony.c | 55 +++
drivers/hid/hid-ids.h | 1 +
2 files changed, 56 insertions(+)
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index 3f0ed6a95223..ca556d39da2a 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -21,6 +21,39 @@
#include "hid-ids.h"
+#define CH_WIRELESS_CTL_REPORT_ID 0x11
+
+static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
+{
+ struct hid_device *hdev = report->device;
+ struct input_dev *input;
+
+ if (report->id != CH_WIRELESS_CTL_REPORT_ID || report->maxfield != 1)
+ return 0;
+
+ input = report->field[0]->hidinput->input;
+ if (!input) {
+ hid_warn(hdev, "can't find wireless radio control's input");
+ return 0;
+ }
+
+ input_report_key(input, KEY_RFKILL, 1);
+ input_sync(input);
+ input_report_key(input, KEY_RFKILL, 0);
+ input_sync(input);
+
+ return 1;
+}
+
+static int ch_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
+ return ch_report_wireless(report, data, size);
+
+ return 0;
+}
+
#define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
EV_KEY, (c))
static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
@@ -77,10 +110,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
return rdesc;
}
+static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+
+ hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret) {
+ hid_err(hdev, "Chicony hw start failed: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ }
};
@@ -91,6 +144,8 @@ static struct hid_driver ch_driver = {
.id_table = ch_devices,
.report_fixup = ch_switch12_report_fixup,
.input_mapping = ch_input_mapping,
+ .probe = ch_probe,
+ .raw_event = ch_raw_event,
};
module_hid_driver(ch_driver);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4c5f23640f9c..06d90301a3dc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -270,6 +270,7 @@
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
#define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
+#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
#define USB_DEVICE_ID_ASUS_AK1D0x1125
#define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
#define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
--
2.29.2
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Chris Chiu 於 2020年12月23日 週三 上午12:41寫道：
>
> On Tue, Dec 22, 2020 at 3:41 PM Jian-Hong Pan wrote:
> >
> > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
> > "Wireless Radio Control" feature. For example, the wireless keyboard
> > [04f2:1236] shipped with ASUS all-in-one desktop.
> >
> > After consulting Chicony for this hotkey, learned the device will send
> > with 0x11 as the report ID and 0x1 as the value when the key is pressed
> > down.
> >
> > This patch maps the event as KEY_RFKILL.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > drivers/hid/hid-chicony.c | 58 +++
> > drivers/hid/hid-ids.h | 1 +
> > 2 files changed, 59 insertions(+)
> >
> > diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
> > index 3f0ed6a95223..aca963aa0f1e 100644
> > --- a/drivers/hid/hid-chicony.c
> > +++ b/drivers/hid/hid-chicony.c
> > @@ -21,6 +21,42 @@
> >
> > #include "hid-ids.h"
> >
> > +#define KEY_PRESSED0x01
> > +#define CH_WIRELESS_CTL_REPORT_ID 0x11
> > +
> > +static int ch_report_wireless(struct hid_report *report, u8 *data, int
> > size)
> > +{
> > + struct hid_device *hdev = report->device;
> > + struct input_dev *input;
> > +
> > + if (report->id != CH_WIRELESS_CTL_REPORT_ID ||
> > + report->maxfield != 1 ||
> > + *report->field[0]->value != KEY_PRESSED)
>
> Maybe replace this line with hid_check_keys_pressed() and the KEY_PRESSED
> is not required.
Thanks for your suggestion!
I tried hid_check_keys_pressed(). But, it always returns no key is
pressed in this case.
However, if the idea is: Since there is already a report, there must
be an event from the input. So, the key press checking is duplicated.
This idea makes sense. I will have a modification for this.
Thanks!
Jian-Hong Pan
> > + return 0;
> > +
> > + input = report->field[0]->hidinput->input;
> > + if (!input) {
> > + hid_warn(hdev, "can't find wireless radio control's input");
> > + return 0;
> > + }
> > +
> > + input_report_key(input, KEY_RFKILL, 1);
> > + input_sync(input);
> > + input_report_key(input, KEY_RFKILL, 0);
> > + input_sync(input);
> > +
> > + return 1;
> > +}
> > +
> > +static int ch_raw_event(struct hid_device *hdev,
> > + struct hid_report *report, u8 *data, int size)
> > +{
> > + if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
> > + return ch_report_wireless(report, data, size);
> > +
> > + return 0;
> > +}
> > +
> > #define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
> > EV_KEY, (c))
> > static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> > @@ -77,10 +113,30 @@ static __u8 *ch_switch12_report_fixup(struct
> > hid_device *hdev, __u8 *rdesc,
> > return rdesc;
> > }
> >
> > +static int ch_probe(struct hid_device *hdev, const struct hid_device_id
> > *id)
> > +{
> > + int ret;
> > +
> > + hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
> > + ret = hid_parse(hdev);
> > + if (ret) {
> > + hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> > + if (ret) {
> > + hid_err(hdev, "Chicony hw start failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> >
> > static const struct hid_device_id ch_devices[] = {
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_WIRELESS2) },
> > + { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_WIRELESS3) },
> > { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
> > USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
> > { }
> > };
> > @@ -91,6 +147,8 @@ static struct hid_driver ch_driver = {
> > .id_table = ch_devices,
> > .report_fixup = ch_switch12_report_fixup,
> > .input_mapping = ch_input_mapping,
> > + .probe = ch_probe,
> > + .raw_event = ch_raw_event,
> > };
> > module_hid_driver(ch_driver);
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 4c5f23640f9c..06d90301a3dc 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -270,6 +270,7 @@
> > #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
> > #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
> > #define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
> > +#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
> > #define USB_DEVICE_ID_ASUS_AK1D0x1125
> > #define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
> > #define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
> > --
> > 2.29.2
> >
[PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
"Wireless Radio Control" feature. For example, the wireless keyboard
[04f2:1236] shipped with ASUS all-in-one desktop.
After consulting Chicony for this hotkey, learned the device will send
with 0x11 as the report ID and 0x1 as the value when the key is pressed
down.
This patch maps the event as KEY_RFKILL.
Signed-off-by: Jian-Hong Pan
---
drivers/hid/hid-chicony.c | 58 +++
drivers/hid/hid-ids.h | 1 +
2 files changed, 59 insertions(+)
diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
index 3f0ed6a95223..aca963aa0f1e 100644
--- a/drivers/hid/hid-chicony.c
+++ b/drivers/hid/hid-chicony.c
@@ -21,6 +21,42 @@
#include "hid-ids.h"
+#define KEY_PRESSED0x01
+#define CH_WIRELESS_CTL_REPORT_ID 0x11
+
+static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
+{
+ struct hid_device *hdev = report->device;
+ struct input_dev *input;
+
+ if (report->id != CH_WIRELESS_CTL_REPORT_ID ||
+ report->maxfield != 1 ||
+ *report->field[0]->value != KEY_PRESSED)
+ return 0;
+
+ input = report->field[0]->hidinput->input;
+ if (!input) {
+ hid_warn(hdev, "can't find wireless radio control's input");
+ return 0;
+ }
+
+ input_report_key(input, KEY_RFKILL, 1);
+ input_sync(input);
+ input_report_key(input, KEY_RFKILL, 0);
+ input_sync(input);
+
+ return 1;
+}
+
+static int ch_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
+ return ch_report_wireless(report, data, size);
+
+ return 0;
+}
+
#define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
EV_KEY, (c))
static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
@@ -77,10 +113,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
return rdesc;
}
+static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+
+ hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret) {
+ hid_err(hdev, "Chicony hw start failed: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
static const struct hid_device_id ch_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_WIRELESS3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
{ }
};
@@ -91,6 +147,8 @@ static struct hid_driver ch_driver = {
.id_table = ch_devices,
.report_fixup = ch_switch12_report_fixup,
.input_mapping = ch_input_mapping,
+ .probe = ch_probe,
+ .raw_event = ch_raw_event,
};
module_hid_driver(ch_driver);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4c5f23640f9c..06d90301a3dc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -270,6 +270,7 @@
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
#define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
+#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
#define USB_DEVICE_ID_ASUS_AK1D0x1125
#define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
#define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
--
2.29.2
[PATCH] ALSA: hda/realtek: Enable headset of ASUS UX482EG & B9400CEA with ALC294
Some laptops like ASUS UX482EG & B9400CEA's headset audio does not work
until the quirk ALC294_FIXUP_ASUS_HPE is applied.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 739dbaf54517..1aafc55f1505 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8585,6 +8585,9 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_HPE,
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
{0x14, 0x90170110},
{0x1b, 0x90a70130},
--
2.29.2
[PATCH v2] ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887
The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect
the headset microphone and another headphone jack until
ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied.
The NID 0x15 maps as the headset microphone and NID 0x19 maps as another
headphone jack. Also need the function like alc887_fixup_asus_jack to
enable the audio jacks.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Kailang Yang
---
v2:
- Change the magic numbers to meaningful macros.
- Change snd_hda_codec_write to snd_hda_set_pin_ctl and
snd_hda_set_pin_ctl_cache accroding to Takashi's suggestion
sound/pci/hda/patch_realtek.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d4f17b465892..56c3ee95c8d3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1929,6 +1929,8 @@ enum {
ALC1220_FIXUP_CLEVO_P950,
ALC1220_FIXUP_CLEVO_PB51ED,
ALC1220_FIXUP_CLEVO_PB51ED_PINS,
+ ALC887_FIXUP_ASUS_AUDIO,
+ ALC887_FIXUP_ASUS_HMIC,
};
static void alc889_fixup_coef(struct hda_codec *codec,
@@ -2141,6 +2143,31 @@ static void alc1220_fixup_clevo_pb51ed(struct hda_codec
*codec,
alc_fixup_headset_mode_no_hp_mic(codec, fix, action);
}
+static void alc887_asus_hp_automute_hook(struct hda_codec *codec,
+struct hda_jack_callback *jack)
+{
+ struct alc_spec *spec = codec->spec;
+ unsigned int vref;
+
+ snd_hda_gen_hp_automute(codec, jack);
+
+ if (spec->gen.hp_jack_present)
+ vref = AC_PINCTL_VREF_80;
+ else
+ vref = AC_PINCTL_VREF_HIZ;
+ snd_hda_set_pin_ctl(codec, 0x19, PIN_HP | vref);
+}
+
+static void alc887_fixup_asus_jack(struct hda_codec *codec,
+const struct hda_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+ if (action != HDA_FIXUP_ACT_PROBE)
+ return;
+ snd_hda_set_pin_ctl_cache(codec, 0x1b, PIN_HP);
+ spec->gen.hp_automute_hook = alc887_asus_hp_automute_hook;
+}
+
static const struct hda_fixup alc882_fixups[] = {
[ALC882_FIXUP_ABIT_AW9D_MAX] = {
.type = HDA_FIXUP_PINS,
@@ -2398,6 +2425,20 @@ static const struct hda_fixup alc882_fixups[] = {
.chained = true,
.chain_id = ALC1220_FIXUP_CLEVO_PB51ED,
},
+ [ALC887_FIXUP_ASUS_AUDIO] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x15, 0x02a14150 }, /* use as headset mic, without
its own jack detect */
+ { 0x19, 0x22219420 },
+ {}
+ },
+ },
+ [ALC887_FIXUP_ASUS_HMIC] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc887_fixup_asus_jack,
+ .chained = true,
+ .chain_id = ALC887_FIXUP_ASUS_AUDIO,
+ },
};
static const struct snd_pci_quirk alc882_fixup_tbl[] = {
@@ -2431,6 +2472,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD),
SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V),
SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC),
+ SND_PCI_QUIRK(0x1043, 0x2390, "Asus D700SA", ALC887_FIXUP_ASUS_HMIC),
SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601),
SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS),
SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII",
ALC882_FIXUP_GPIO3),
--
2.28.0
[PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887
The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect
the headset microphone and another headphone jack until
ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied.
The NID 0x15 maps as the headset microphone and NID 0x19 maps as another
headphone jack. Also need the function like alc887_fixup_asus_jack to
enable the audio jacks.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Kailang Yang
---
sound/pci/hda/patch_realtek.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d4f17b465892..8d0928bdc9ff 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1929,6 +1929,8 @@ enum {
ALC1220_FIXUP_CLEVO_P950,
ALC1220_FIXUP_CLEVO_PB51ED,
ALC1220_FIXUP_CLEVO_PB51ED_PINS,
+ ALC887_FIXUP_ASUS_AUDIO,
+ ALC887_FIXUP_ASUS_HMIC,
};
static void alc889_fixup_coef(struct hda_codec *codec,
@@ -2141,6 +2143,30 @@ static void alc1220_fixup_clevo_pb51ed(struct hda_codec
*codec,
alc_fixup_headset_mode_no_hp_mic(codec, fix, action);
}
+static void alc887_asus_hp_automute_hook(struct hda_codec *codec,
+struct hda_jack_callback *jack)
+{
+ struct alc_spec *spec = codec->spec;
+ int vref;
+
+ snd_hda_gen_hp_automute(codec, jack);
+
+ vref = spec->gen.hp_jack_present ? 0xc4 : 0xc0;
+ snd_hda_codec_write(codec, 0x19, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+ vref);
+}
+
+static void alc887_fixup_asus_jack(struct hda_codec *codec,
+const struct hda_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+ if (action != HDA_FIXUP_ACT_PROBE)
+ return;
+ snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+ 0xc0);
+ spec->gen.hp_automute_hook = alc887_asus_hp_automute_hook;
+}
+
static const struct hda_fixup alc882_fixups[] = {
[ALC882_FIXUP_ABIT_AW9D_MAX] = {
.type = HDA_FIXUP_PINS,
@@ -2398,6 +2424,20 @@ static const struct hda_fixup alc882_fixups[] = {
.chained = true,
.chain_id = ALC1220_FIXUP_CLEVO_PB51ED,
},
+ [ALC887_FIXUP_ASUS_AUDIO] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x15, 0x02a14150 }, /* use as headset mic, without
its own jack detect */
+ { 0x19, 0x22219420 },
+ {}
+ },
+ },
+ [ALC887_FIXUP_ASUS_HMIC] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc887_fixup_asus_jack,
+ .chained = true,
+ .chain_id = ALC887_FIXUP_ASUS_AUDIO,
+ },
};
static const struct snd_pci_quirk alc882_fixup_tbl[] = {
@@ -2431,6 +2471,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD),
SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V),
SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC),
+ SND_PCI_QUIRK(0x1043, 0x2390, "Asus D700SA", ALC887_FIXUP_ASUS_HMIC),
SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601),
SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS),
SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII",
ALC882_FIXUP_GPIO3),
--
2.28.0
Re: [QUESTION] Enable the wireless module on Pinebook Pro
I forgot to mail to Dan Johansen as well. Jian-Hong Pan 於 2020年9月30日 週三 下午4:15寫道： > > Hi, > > According to the preloaded system Manjaro ARM on Pinebook Pro [1], I > found the firmware files in ap6256-firmware package [2] enable the > wireless module, including WiFi and Bluetooth. > If we want to redistribute the firmware files to linux-firmware > repository or other distros, which kind of license should follow? > > [1] https://www.pine64.org/pinebook-pro/ > [2] https://gitlab.manjaro.org/manjaro-arm/packages/community/ap6256-firmware > > Jian-Hong Pan
[QUESTION] Enable the wireless module on Pinebook Pro
Hi, According to the preloaded system Manjaro ARM on Pinebook Pro [1], I found the firmware files in ap6256-firmware package [2] enable the wireless module, including WiFi and Bluetooth. If we want to redistribute the firmware files to linux-firmware repository or other distros, which kind of license should follow? [1] https://www.pine64.org/pinebook-pro/ [2] https://gitlab.manjaro.org/manjaro-arm/packages/community/ap6256-firmware Jian-Hong Pan
[PATCH] arm64: dts: rockchip: disable USB type-c DisplayPort
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
extcon or phy
kernel: cdn-dp: probe of fec0.dp failed with error -22
Then, the device halts all of the DRM related device jobs. For example,
the operations: vop_component_ops, vop_component_ops and
rockchip_dp_component_ops cannot be bound to corresponding devices. So,
Xorg cannot find the correct DRM device.
The USB type-C DisplayPort does not work for now. So, disable the
DisplayPort node until the type-C phy work has been done.
Link: https://patchwork.kernel.org/patch/11794141/#23639877
Signed-off-by: Jian-Hong Pan
---
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 06d48338c836..d624c595c533 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -380,7 +380,7 @@ mains_charger: dc-charger {
};
_dp {
- status = "okay";
+ status = "disabled";
};
_b0 {
--
2.28.0
Re: [PATCH] drm/rockchip: skip probed failed device
Heiko Stübner 於 2020年9月23日 週三 下午7:16寫道：
>
> Am Mittwoch, 23. September 2020, 13:05:26 CEST schrieb Robin Murphy:
> > On 2020-09-23 07:59, Jian-Hong Pan wrote:
> > > The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
> > >
> > > kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR*
> > > missing extcon or phy
> > > kernel: cdn-dp: probe of fec0.dp failed with error -22
> >
> > Wouldn't it make more sense to simply not enable the DisplayPort node in
> > the upstream DT, until the type-C phy work has been done to make it
> > usable at all?
>
> Or alternatively just disable the cdn-dp Rockchip driver in the kernel config,
> which results in it also not getting probed.
This may be the simplest way.
However, considering generic distro kernels have a policy to enable
all drivers, disabling the DisplayPort node in the upstream DT, until
the type-C phy work has been done may be a better solution for now.
I can prepare a patch for this.
Jian-Hong Pan
> > AIUI the "official" Manjaro kernel is carrying a bunch of
> > hacks to make type-C work via extcon, but they know that isn't an
> > upstreamable solution.
> >
> > Robin.
> >
> > > Then, the device halts all of the DRM related device jobs. For example,
> > > the operations: vop_component_ops, vop_component_ops and
> > > rockchip_dp_component_ops cannot be bound to corresponding devices. So,
> > > Xorg cannot find the correct DRM device.
> > >
> > > This patch skips the probing failed devices to fix this issue.
> > >
> > > Link:
> > > http://lists.infradead.org/pipermail/linux-rockchip/2020-September/022352.html
> > > Signed-off-by: Jian-Hong Pan
> > > ---
> > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > index 0f3eb392fe39..de13588602b4 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > @@ -331,6 +331,12 @@ static struct component_match
> > > *rockchip_drm_match_add(struct device *dev)
> > >
> > > if (!d)
> > > break;
> > > + if (!d->driver) {
> > > + DRM_DEV_ERROR(d,
> > > + "%s did not probe successfully",
> > > + drv->driver.name);
> > > + continue;
> > > + }
> > >
> > > device_link_add(dev, d, DL_FLAG_STATELESS);
> > > component_match_add(dev, , compare_dev, d);
[PATCH] drm/rockchip: skip probed failed device
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
extcon or phy
kernel: cdn-dp: probe of fec0.dp failed with error -22
Then, the device halts all of the DRM related device jobs. For example,
the operations: vop_component_ops, vop_component_ops and
rockchip_dp_component_ops cannot be bound to corresponding devices. So,
Xorg cannot find the correct DRM device.
This patch skips the probing failed devices to fix this issue.
Link:
http://lists.infradead.org/pipermail/linux-rockchip/2020-September/022352.html
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 0f3eb392fe39..de13588602b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -331,6 +331,12 @@ static struct component_match
*rockchip_drm_match_add(struct device *dev)
if (!d)
break;
+ if (!d->driver) {
+ DRM_DEV_ERROR(d,
+ "%s did not probe successfully",
+ drv->driver.name);
+ continue;
+ }
device_link_add(dev, d, DL_FLAG_STATELESS);
component_match_add(dev, , compare_dev, d);
--
2.28.0
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime,
Thanks for version 5 patch series!
I applied it based on linux-next tag next-20200828 and build it with
the config [1] to test on RPi 4
However, It fails to get HDMI state machine clock and pixel bcb clock.
Then, vc4-drm probes failed. Full dmseg [2]:
[2.552675] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
HDMI state machine clock
[2.557974] raspberrypi-firmware soc:firmware: Attached to firmware
from 2020-06-01T13:23:40
[2.567612] of_clk_hw_onecell_get: invalid index 14
[2.567636] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
pixel bvb clock
[2.567664] vc4-drm gpu: failed to bind fef00700.hdmi (ops vc4_hdmi_ops): -2
[2.567731] vc4-drm gpu: master bind failed: -2
[2.567755] vc4-drm: probe of gpu failed with error -2
I decompile bcm2711-rpi-4-b.dtb. Both hdmi@7ef00700 and hdmi@7ef05700
show the clocks member.
hdmi@7ef00700 {
compatible = "brcm,bcm2711-hdmi0";
reg = <0x7ef00700 0x300 0x7ef00300 0x200 0x7ef00f00 0x80
0x7ef00f80 0x80 0x7ef01b00 0x200 0x7ef01f00 0x400 0x7ef00200 0x80
0x7ef04300 0x100 0x7ef2 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x00>;
ddc = <0x18>;
dmas = <0x19 0x0a>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x00 0x1a>;
};
hdmi@7ef05700 {
compatible = "brcm,bcm2711-hdmi1";
reg = <0x7ef05700 0x300 0x7ef05300 0x200 0x7ef05f00 0x80
0x7ef05f80 0x80 0x7ef06b00 0x200 0x7ef06f00 0x400 0x7ef00280 0x80
0x7ef09300 0x100 0x7ef2 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
ddc = <0x1b>;
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x01>;
dmas = <0x19 0x11>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x01 0x1a>;
};
Also re-check runtime device tree, they are the same values as mentioned above:
$ xxd /proc/device-tree/soc/hdmi@7ef00700/clocks
: 0010 000d 0010 000e
0010: 0017 001a
$ xxd /proc/device-tree/soc/hdmi@7ef05700/clocks
: 0010 000d 0010 000e
0010: 0017 0001 001a
Do I miss something?
[1]:
https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-config
[2]:
https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-dmesg-log
Jian-Hong Pan
[PATCH] brcm: Add 4356 based AP6356S NVRAM for the khadas VIM2
Add a NVRAM file for the wireless module used in khadas VIM2. This
source comes from khadas fenix project's commit 022fdc3a1333 ("hwpacks:
wlan-firmware: add AP6356S firmware for mainline linux"). [1]
[1]:
https://github.com/khadas/fenix/commit/022fdc3a1333d2d16f84c2e59e4507c92a668a3d
Suggested-by: Nick Xie
Signed-off-by: Jian-Hong Pan
---
brcm/brcmfmac4356-sdio.khadas,vim2.txt | 128 +
1 file changed, 128 insertions(+)
create mode 100644 brcm/brcmfmac4356-sdio.khadas,vim2.txt
diff --git a/brcm/brcmfmac4356-sdio.khadas,vim2.txt
b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
new file mode 100644
index 000..4c286cc
--- /dev/null
+++ b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
@@ -0,0 +1,128 @@
+#AP6356SL_V1.1_NVRAM_20150805
+#Modified from AP6356SDP_V1.0_NVRAM_20150216
+NVRAMRev=$Rev: 373428 $
+sromrev=11
+boardrev=0x1121
+boardtype=0x073e
+boardflags=0x02400201
+boardflags2=0x00802000
+boardflags3=0x010a
+macaddr=00:90:4c:1a:10:01
+ccode=0x5855
+regrev=1
+antswitch=0
+pdgain5g=4
+pdgain2g=4
+tworangetssi2g=0
+tworangetssi5g=0
+paprdis=0
+femctrl=10
+vendid=0x14e4
+devid=0x43a3
+manfid=0x2d0
+nocrc=1
+otpimagesize=502
+xtalfreq=37400
+rxgains2gelnagaina0=0
+rxgains2gtrisoa0=7
+rxgains2gtrelnabypa0=0
+rxgains5gelnagaina0=0
+rxgains5gtrisoa0=11
+rxgains5gtrelnabypa0=0
+rxgains5gmelnagaina0=0
+rxgains5gmtrisoa0=13
+rxgains5gmtrelnabypa0=0
+rxgains5ghelnagaina0=0
+rxgains5ghtrisoa0=12
+rxgains5ghtrelnabypa0=0
+rxgains2gelnagaina1=0
+rxgains2gtrisoa1=7
+rxgains2gtrelnabypa1=0
+rxgains5gelnagaina1=0
+rxgains5gtrisoa1=10
+rxgains5gtrelnabypa1=0
+rxgains5gmelnagaina1=0
+rxgains5gmtrisoa1=11
+rxgains5gmtrelnabypa1=0
+rxgains5ghelnagaina1=0
+rxgains5ghtrisoa1=11
+rxgains5ghtrelnabypa1=0
+rxchain=3
+txchain=3
+aa2g=3
+aa5g=3
+agbg0=2
+agbg1=2
+aga0=2
+aga1=2
+tssipos2g=1
+extpagain2g=2
+tssipos5g=1
+extpagain5g=2
+tempthresh=255
+tempoffset=255
+rawtempsense=0x1ff
+pa2ga0=-135,5769,-647
+pa2ga1=-143,6023,-677
+pa5ga0=-183,5746,-697,-172,5801,-685,-176,5707,-680,-180,5445,-659
+pa5ga1=-186,5543,-669,-193,5506,-675,-210,5282,-661,-199,5367,-665
+subband5gver=0x4
+pdoffsetcckma0=0x4
+pdoffsetcckma1=0x4
+pdoffset40ma0=0x
+pdoffset80ma0=0x
+pdoffset40ma1=0x
+pdoffset80ma1=0x
+maxp2ga0=72
+maxp5ga0=69,70,69,68
+maxp2ga1=71
+maxp5ga1=67,67,67,67
+cckbw202gpo=0x1222
+cckbw20ul2gpo=0x
+mcsbw202gpo=0x99E644422
+mcsbw402gpo=0xE9744424
+dot11agofdmhrbw202gpo=0x
+ofdmlrbw202gpo=0x0022
+mcsbw205glpo=0xEEA86661
+mcsbw405glpo=0xEEB86663
+mcsbw805glpo=0xEEB86663
+mcsbw205gmpo=0xAAA86663
+mcsbw405gmpo=0xECB86663
+mcsbw805gmpo=0xEEA86663
+mcsbw205ghpo=0xCC986663
+mcsbw405ghpo=0xEEA86663
+mcsbw805ghpo=0xEEA86663
+mcslr5glpo=0x
+mcslr5gmpo=0x
+mcslr5ghpo=0x
+sb20in40hrpo=0x0
+sb20in80and160hr5glpo=0x0
+sb40and80hr5glpo=0x0
+sb20in80and160hr5gmpo=0x0
+sb40and80hr5gmpo=0x0
+sb20in80and160hr5ghpo=0x0
+sb40and80hr5ghpo=0x0
+sb20in40lrpo=0x0
+sb20in80and160lr5glpo=0x0
+sb40and80lr5glpo=0x0
+sb20in80and160lr5gmpo=0x0
+sb40and80lr5gmpo=0x0
+sb20in80and160lr5ghpo=0x0
+sb40and80lr5ghpo=0x0
+dot11agduphrpo=0x0
+dot11agduplrpo=0x0
+phycal_tempdelta=255
+temps_period=15
+temps_hysteresis=15
+rssicorrnorm_c0=4,4
+rssicorrnorm_c1=4,4
+rssicorrnorm5g_c0=1,2,3,1,2,3,6,6,8,6,6,8
+rssicorrnorm5g_c1=1,2,3,2,2,2,7,7,8,7,7,8
+
+swctrlmap_2g=0x1040,0x4010,0x4010,0x200010,0xff
+swctrlmap_5g=0x0202,0x0101,0x0101,0x00,0x47
+swctrlmapext_5g=0x,0x,0x,0x00,0x000
+swctrlmapext_2g=0x,0x,0x,0x00,0x000
+
+muxenab=0x10
+
--
2.28.0
[PATCH] ALSA: hda/realtek: Enable headset mic of Acer TravelMate B311R-31 with ALC256
The Acer TravelMate B311R-31 laptop's audio (1025:1430) with ALC256
cannot detect the headset microphone until
ALC256_FIXUP_ACER_MIC_NO_PRESENCE quirk maps the NID 0x19 as the headset
mic pin.
Signed-off-by: Jian-Hong Pan
---
Re-send for wrong email address
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 194ffa8c66ce..0585ac97faf4 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6152,6 +6152,7 @@ enum {
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
ALC269VC_FIXUP_ACER_HEADSET_MIC,
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE,
+ ALC256_FIXUP_ACER_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7359,6 +7360,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC256_FIXUP_ACER_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x02a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7387,6 +7397,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1430, "Acer TravelMate B311R-31",
ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440",
ALC292_FIXUP_DELL_E7X),
--
2.27.0
Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, Thanks for your version 4 patch again. I took the patches and applied them upon next-20200708. I make system cold reboot to multi-user target and the text console shows on the screen. Then, I simply hot re-plug the HDMI cable on HDMI0 port, I not only lose the text console on the screen (the display shows blank, backlight is off), but also kernel does not probe modes for the HDMI connector again. But HDMI1 does probe modes again for hot re-plugging. So, HDMI1 does not hit the issue like HDMI0. * System probes modes only once for HDMI0 port (HDMI-A-1), even hot re-plug HDMI cable to the same port: [ 15.611072] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:HDMI-A-1] probed modes : [ 15.611079] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 15.611085] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 15.611298] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 15.611303] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] [ 15.612184] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] disconnected [ 15.612191] [drm:drm_client_modeset_probe] connector 32 enabled? yes [ 15.612194] [drm:drm_client_modeset_probe] connector 38 enabled? no [ 15.612206] [drm:drm_client_modeset_probe] Not using firmware configuration [ 15.612213] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 32 [ 15.612218] [drm:drm_client_modeset_probe] looking for preferred mode on connector 32 0 [ 15.612221] [drm:drm_client_modeset_probe] found mode 1920x1080 ... [ 108.263384] [drm:output_poll_execute] [CONNECTOR:32:HDMI-A-1] status updated from disconnected to connected [ 108.264307] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] [ 108.264312] [drm:drm_client_modeset_probe] [ 108.264321] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:HDMI-A-1] [ 109.303379] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] [ 109.304258] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] disconnected [ 109.304266] [drm:drm_client_modeset_probe] No connectors reported connected with modes * System probes modes again for HDMI1 port (HDMI-A-2), whenever hot re-plug the HDMI cable: [ 797.974649] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] probed modes : [ 797.974656] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 797.974662] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 797.974874] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 797.974880] [drm:drm_client_modeset_probe] connector 32 enabled? no [ 797.974883] [drm:drm_client_modeset_probe] connector 38 enabled? yes [ 797.974895] [drm:drm_client_modeset_probe] Not using firmware configuration [ 797.974901] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 38 [ 797.974905] [drm:drm_client_modeset_probe] looking for preferred mode on connector 38 0 [ 797.974908] [drm:drm_client_modeset_probe] found mode 1920x1080 ... [ 852.242615] vc4-drm gpu: [drm:drm_client_dev_hotplug] fbdev: ret=0 [ 873.718277] [drm:output_poll_execute] [CONNECTOR:38:HDMI-A-2] status updated from disconnected to connected [ 873.718332] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] [ 873.718338] [drm:drm_client_modeset_probe] ... [ 874.264013] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] probed modes : [ 874.264020] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 874.264026] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 874.264239] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 874.264244] [drm:drm_client_modeset_probe] connector 32 enabled? no [ 874.264247] [drm:drm_client_modeset_probe] connector 38 enabled? yes [ 874.264259] [drm:drm_client_modeset_probe] Not using firmware configuration [ 874.264264] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 38 [ 874.264268] [drm:drm_client_modeset_probe] looking for preferred mode on connector 38 0 [ 874.264272] [drm:drm_client_modeset_probe] found mode 1920x1080 Here is the full dmesg: https://gist.github.com/starnight/5ffb86af552fedb9b6e5741d0540a878#file-dmesg-v4-log
[PATCH v3 3/3] ALSA: hda/realtek: Enable headset mic of Acer Veriton N4660G with ALC269VC
The Acer Veriton N4660G desktop's audio (1025:1248) with ALC269VC cannot
detect the headset microphone until ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE
quirk maps the NID 0x18 as the headset mic pin.
Signed-off-by: Jian-Hong Pan
---
v3: Change the chained ID to ALC269_FIXUP_HEADSET_MIC according to
Realtek's suggestion
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index be18b304e731..c2e6a6b7ea5b 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6151,6 +6151,7 @@ enum {
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
ALC269VC_FIXUP_ACER_HEADSET_MIC,
+ ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7349,6 +7350,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x18, 0x01a11130 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7370,6 +7380,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
+ SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.27.0
[PATCH v3 2/3] ALSA: hda/realtek: Enable headset mic of Acer C20-820 with ALC269VC
The Acer Aspire C20-820 AIO's audio (1025:1065) with ALC269VC can't
detect the headset microphone until ALC269VC_FIXUP_ACER_HEADSET_MIC
quirk maps the NID 0x18 as the headset mic pin.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
v3: Change the chained ID to ALC269_FIXUP_HEADSET_MIC according to
Realtek's suggestion
v2: Change the chained ID to ALC269_FIXUP_HEADSET_MODE according to
Realtek's suggestion
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 13c32655df44..be18b304e731 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6150,6 +6150,7 @@ enum {
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
+ ALC269VC_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7339,6 +7340,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC269VC_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x18, 0x02a11030 }, /* use as headset mic */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7354,6 +7364,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820",
ALC269VC_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
--
2.27.0
[PATCH v3 1/3] ALSA: hda/realtek - Enable audio jacks of Acer vCopperbox with ALC269VC
The Acer desktop vCopperbox with ALC269VC cannot detect the MIC of
headset, the line out and internal speaker until
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Chris Chiu
---
v3: Change the chained ID to ALC269_FIXUP_HEADSET_MIC according to
Realtek's suggestion
sound/pci/hda/patch_realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 737ef82a75fd..13c32655df44 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6149,6 +6149,7 @@ enum {
ALC236_FIXUP_HP_MUTE_LED,
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7327,6 +7328,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x14, 0x90100120 }, /* use as internal speaker */
+ { 0x18, 0x02a111f0 }, /* use as headset mic, without
its own jack detect */
+ { 0x1a, 0x01011020 }, /* use as line out */
+ { },
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7346,6 +7358,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
+ SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.27.0
[PATCH v2 1/3] ALSA: hda/realtek - Enable audio jacks of Acer vCopperbox with ALC269VC
The Acer desktop vCopperbox with ALC269VC cannot detect the MIC of
headset, the line out and internal speaker until
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 737ef82a75fd..dfb4bca07d3f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6149,6 +6149,7 @@ enum {
ALC236_FIXUP_HP_MUTE_LED,
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7327,6 +7328,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x14, 0x90100120 }, /* use as internal speaker */
+ { 0x18, 0x02a111f0 }, /* use as headset mic, without
its own jack detect */
+ { 0x1a, 0x01011020 }, /* use as line out */
+ { },
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7346,6 +7358,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
+ SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.27.0
[PATCH 3/3] ALSA: hda/realtek: Enable headset mic of Acer Veriton N4660G with ALC269VC
The Acer Veriton N4660G desktop's audio (1025:1248) with ALC269VC cannot
detect the headset microphone until ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE
quirk maps the NID 0x18 as the headset mic pin.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3255da8b3849..02054a2a742f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6151,6 +6151,7 @@ enum {
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
ALC269VC_FIXUP_ACER_HEADSET_MIC,
+ ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7349,6 +7350,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x18, 0x01a11130 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7370,6 +7380,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
+ SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.27.0
[PATCH 2/3] ALSA: hda/realtek: Enable headset mic of Acer C20-820 with ALC269VC
The Acer Aspire C20-820 AIO's audio (1025:1065) with ALC269VC can't
detect the headset microphone until ALC269VC_FIXUP_ACER_HEADSET_MIC
quirk maps the NID 0x18 as the headset mic pin.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index dfb4bca07d3f..3255da8b3849 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6150,6 +6150,7 @@ enum {
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
+ ALC269VC_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7339,6 +7340,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC269VC_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x18, 0x02a11030 }, /* use as headset mic */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7354,6 +7364,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572",
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820",
ALC269VC_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
--
2.27.0
[PATCH 1/3] ALSA: hda/realtek - Enable audio jacks of Acer vCopperbox with ALC269VC
The Acer desktop vCopperbox with ALC269VC cannot detect the MIC of
headset, the line out and internal speaker until
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 737ef82a75fd..dfb4bca07d3f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6149,6 +6149,7 @@ enum {
ALC236_FIXUP_HP_MUTE_LED,
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7327,6 +7328,17 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x14, 0x90100120 }, /* use as internal speaker */
+ { 0x18, 0x02a111f0 }, /* use as headset mic, without
its own jack detect */
+ { 0x1a, 0x01011020 }, /* use as line out */
+ { },
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7346,6 +7358,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
+ SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.27.0
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年6月29日 週一 下午10:21寫道： > > Hi! > > On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年6月2日 週二 下午7:04寫道： > > > > > > Hi, > > > > > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote: > > > > Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > > > > > > > > > Hi Daniel, > > > > > > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard > > > > > > wrote: > > > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and > > > > > > > Jian-Hong) if you > > > > > > > want. > > > > > > > > > > > > That would be great, although given the potentially inconsistent > > > > > > results we've been seeing so far it would be great if you could > > > > > > additionally push a git branch somewhere. > > > > > > That way we can have higher confidence that we are applying exactly > > > > > > the same patches to the same base etc. > > > > > > > > > > So I sent a new iteration yesterday, and of course forgot to cc > > > > > you... Sorry for > > > > > that. > > > > > > > > > > I've pushed my current branch here: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms > > > > > > > > Thanks to Maxime! > > > > > > > > I have tried your repository on branch rpi4-kms. The DRM VC4 is used! > > > > But got some issues: > > > > 1. Some weird error message in dmesg. Not sure it is related, or not > > > > [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get > > > > HDMI state machine clock > > > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 > > > > > > That's a deferred probing. The first time the HDMI driver is being > > > probed, the firmware clock driver has not been probed yet. It's making > > > another attempt later on, which succeeds. > > > > > > > 2. The screen flashes suddenly sometimes. > > > > I append drm.debug=0x3 to boot command. Whenever, the screen flashes, > > I notice the logs like this: > > > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling > > vblank on crtc 3, ret: 0 > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 159 (2) > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 154 (1) > > Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling > > vblank on crtc 3 > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > auth=1, DRM_IOCTL_MODE_CURSOR > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > auth=1, DRM_IOCTL_MODE_CURSOR2 > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1) > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1) > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling > > vblank on crtc 3, ret: 0 > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 159 (2) > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 154 (2) > > > > Here is the full log > > https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56 > > > > > > 3. The higher resolutions, like 1920x1080 ... are lost after hot > > > > re-plug HDMI cable (HDMI0) > > > > I should explain this in more detail. Here are the steps to reproduce > > this issue: > > 1. Before unplug the HDMI cable from HDMI0 port. > > $ xrandr > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 > > HDMI-1 connected primary 1920x1080+0+0 (normal left inverted rig
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年6月2日 週二 下午7:04寫道： > > Hi, > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > > > > > Hi Daniel, > > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and > > > > > Jian-Hong) if you > > > > > want. > > > > > > > > That would be great, although given the potentially inconsistent > > > > results we've been seeing so far it would be great if you could > > > > additionally push a git branch somewhere. > > > > That way we can have higher confidence that we are applying exactly > > > > the same patches to the same base etc. > > > > > > So I sent a new iteration yesterday, and of course forgot to cc you... > > > Sorry for > > > that. > > > > > > I've pushed my current branch here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms > > > > Thanks to Maxime! > > > > I have tried your repository on branch rpi4-kms. The DRM VC4 is used! > > But got some issues: > > 1. Some weird error message in dmesg. Not sure it is related, or not > > [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get > > HDMI state machine clock > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 > > That's a deferred probing. The first time the HDMI driver is being > probed, the firmware clock driver has not been probed yet. It's making > another attempt later on, which succeeds. > > > 2. The screen flashes suddenly sometimes. I append drm.debug=0x3 to boot command. Whenever, the screen flashes, I notice the logs like this: Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: clock 148500 kHz framedur 1666 linedur 14814 Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling vblank on crtc 3, ret: 0 Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2) Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1) Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling vblank on crtc 3 Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, auth=1, DRM_IOCTL_MODE_CURSOR Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, auth=1, DRM_IOCTL_MODE_CURSOR2 Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1) Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1) Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: clock 148500 kHz framedur 1666 linedur 14814 Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling vblank on crtc 3, ret: 0 Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2) Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2) Here is the full log https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56 > > 3. The higher resolutions, like 1920x1080 ... are lost after hot > > re-plug HDMI cable (HDMI0) I should explain this in more detail. Here are the steps to reproduce this issue: 1. Before unplug the HDMI cable from HDMI0 port. $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.0059.94 1920x1080i60.0050.0059.94 1680x1050 59.88 1280x1024 75.0260.02 1440x900 59.90 1280x960 60.00 1152x864 75.00 1280x720 60.0050.0059.94 1440x576 50.00 1024x768 75.0370.0760.00 1440x480 60.0059.94 832x624 74.55 800x600 72.1975.0060.3256.25 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 HDMI-2 disconnected (normal left inverted right x axis y axis) 2. Unplug the HDMI cable from HDMI0 port. 3. Plug the HDMI cable to **HDMI1** port. $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 HDMI-1 disconnected (normal left inverted right x axis y axis) HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.0059.94 1920x1080i
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > Hi Daniel, > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if > > > you > > > want. > > > > That would be great, although given the potentially inconsistent > > results we've been seeing so far it would be great if you could > > additionally push a git branch somewhere. > > That way we can have higher confidence that we are applying exactly > > the same patches to the same base etc. > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry > for > that. > > I've pushed my current branch here: > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms Thanks to Maxime! I have tried your repository on branch rpi4-kms. The DRM VC4 is used! But got some issues: 1. Some weird error message in dmesg. Not sure it is related, or not [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get HDMI state machine clock https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 2. The screen flashes suddenly sometimes. 3. The higher resolutions, like 1920x1080 ... are lost after hot re-plug HDMI cable (HDMI0) Jian-Hong Pan
[PATCH 3/3] ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295
The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the
headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk
applied.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index dcb97b39be6e..36832645de78 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7393,6 +7393,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT",
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
+ SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
--
2.26.2
[PATCH 2/3] ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295
The ASUS laptop UX550GE with ALC295 can't detect the headset microphone
until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 6c996df16201..dcb97b39be6e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8003,6 +8003,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60130},
{0x17, 0x90170110},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60120},
+ {0x17, 0x90170110},
+ {0x21, 0x04211030}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
{0x12, 0x90a60130},
{0x17, 0x90170110},
--
2.26.2
[PATCH 1/3] ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295
From: Chris Chiu
The ASUS laptop GL503VM with ALC295 can't detect the headset microphone.
The headset microphone does not work until pin 0x19 is enabled for it.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c16f63957c5a..6c996df16201 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6083,6 +6083,7 @@ enum {
ALC285_FIXUP_HP_GPIO_LED,
ALC285_FIXUP_HP_MUTE_LED,
ALC236_FIXUP_HP_MUTE_LED,
+ ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7216,6 +7217,15 @@ static const struct hda_fixup alc269_fixups[] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc236_fixup_hp_mute_led,
},
+ [ALC295_FIXUP_ASUS_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1913c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7993,6 +8003,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60130},
{0x17, 0x90170110},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS",
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
{0x14, 0x90170110},
{0x21, 0x04211020}),
--
2.26.2
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Jian-Hong Pan 於 2020年5月8日 週五 下午2:20寫道： > > Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道： > > > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote: > > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > > > > > > > Hi, > > > > > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > > > > Hi Maxime, > > > > > > > > > > Thanks for your V2 patch series! I'm testing it. > > > > > > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and > > > > > built. > > > > > System can boot into console text mode, but no graphic UI. > > > > > > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > > > > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > > > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent > > > > > 'vc4-hdmi' already present! > > > > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> > > > > > fef00700.hdmi mapping ok > > > > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > > > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > > > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > > > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' > > > > > already present! > > > > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> > > > > > fef05700.hdmi mapping ok > > > > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > > > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > > > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > > > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > > > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > > > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 > > > > > ) > > > > > [5.589297] fb0: switching to vc4drmfb from simple > > > > > [5.589433] Console: switching to colour dummy device 80x25 > > > > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 > > > > > (21.10.2013). > > > > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > > > > [5.601079] [ cut here ] > > > > > [5.601095] WARNING: CPU: 2 PID: 127 at > > > > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > [5.601097] Modules linked in: > > > > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > > > > 5.7.0-rc2-00091-ga181df59a930 #7 > > > > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > > > > [5.601112] Workqueue: events deferred_probe_work_func > > > > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > > > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > > [5.601124] sp : 80001217b410 > > > > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > > > > [5.601129] x27: f650d400 x26: 8a50 > > > > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > > > > [5.601135] x23: 0a50 x22: 0300 > > > > > [5.601137] x21: 08d9ee20 x20: ec535080 > > > > > [5.601140] x19: 00010989e7c0 x18: > > > > > [5.601142] x17: 0001 x16: 5207 > > > > > [5.601145] x15: 4932ad293c92 x14: 0137 > > > >
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道： > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > > > > > Hi, > > > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > > > Hi Maxime, > > > > > > > > Thanks for your V2 patch series! I'm testing it. > > > > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and > > > > built. > > > > System can boot into console text mode, but no graphic UI. > > > > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent > > > > 'vc4-hdmi' already present! > > > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi > > > > mapping ok > > > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already > > > > present! > > > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi > > > > mapping ok > > > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 > > > > ) > > > > [5.589297] fb0: switching to vc4drmfb from simple > > > > [5.589433] Console: switching to colour dummy device 80x25 > > > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 > > > > (21.10.2013). > > > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > > > [5.601079] [ cut here ] > > > > [5.601095] WARNING: CPU: 2 PID: 127 at > > > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > > > [5.601097] Modules linked in: > > > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > > > 5.7.0-rc2-00091-ga181df59a930 #7 > > > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > > > [5.601112] Workqueue: events deferred_probe_work_func > > > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > [5.601124] sp : 80001217b410 > > > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > > > [5.601129] x27: f650d400 x26: 8a50 > > > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > > > [5.601135] x23: 0a50 x22: 0300 > > > > [5.601137] x21: 08d9ee20 x20: ec535080 > > > > [5.601140] x19: 00010989e7c0 x18: > > > > [5.601142] x17: 0001 x16: 5207 > > > > [5.601145] x15: 4932ad293c92 x14: 0137 > > > > [5.601147] x13: 800010015000 x12: 0001 > > > > [5.601150] x11: 0001 x10: > > > > [5.601152] x9 : x8 : 800010015038 > > > > [5.601154] x7 : 0001 x6 : 80001217b368 > > > > [5.601157] x5 : x4 : 004c > > > > [5.601159] x3 : x2 : 8000113b4ac0 > > > > [5.601162] x1 : 8000120c5
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > Hi, > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > Hi Maxime, > > > > Thanks for your V2 patch series! I'm testing it. > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built. > > System can boot into console text mode, but no graphic UI. > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' > > already present! > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi > > mapping ok > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already > > present! > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi > > mapping ok > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops) > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops) > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops) > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops) > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops) > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 ) > > [5.589297] fb0: switching to vc4drmfb from simple > > [5.589433] Console: switching to colour dummy device 80x25 > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > [5.601079] [ cut here ] > > [5.601095] WARNING: CPU: 2 PID: 127 at > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601097] Modules linked in: > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > 5.7.0-rc2-00091-ga181df59a930 #7 > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > [5.601112] Workqueue: events deferred_probe_work_func > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601124] sp : 80001217b410 > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > [5.601129] x27: f650d400 x26: 8a50 > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > [5.601135] x23: 0a50 x22: 0300 > > [5.601137] x21: 08d9ee20 x20: ec535080 > > [5.601140] x19: 00010989e7c0 x18: > > [5.601142] x17: 0001 x16: 5207 > > [5.601145] x15: 4932ad293c92 x14: 0137 > > [5.601147] x13: 800010015000 x12: 0001 > > [5.601150] x11: 0001 x10: > > [5.601152] x9 : x8 : 800010015038 > > [5.601154] x7 : 0001 x6 : 80001217b368 > > [5.601157] x5 : x4 : 004c > > [5.601159] x3 : x2 : 8000113b4ac0 > > [5.601162] x1 : 8000120c5f44 x0 : dc8984ff > > [5.601164] Call trace: > > [5.601169] vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248 > > [5.601179] vc4_atomic_complete_commit+0x400/0x558 > > [5.601182] vc4_atomic_commit+0x1e0/0x200 > > [5.601185] drm_atomic_commit+0x4c/0x60 > > [5.601190] drm_client_modeset_commit_atomic.isra.0+0x17c/0x238 > > [5.601192] drm_client_modeset_commit_locked+0x5c/0x198 > > [5.601195] drm_client_modeset_commit+0x30/0x58 > > [5.601201] drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0 > > [5.601204] drm_fb_helper_set_par+0x30/0x68 > > [5.601208] fbcon_init+0x3d4/0x598 > > [5.601212] visual_init
[PATCH] drm/radeon: drm/amdgpu: Disable [1002:6611] in radeon
The AMD/ATI Oland [1002:6611]'s HDMI output status is not synchronous
as shown on UI after hot re-plug the HDMI cable, if it is radeon in
used. The amdgpu module does not hit this issue.
This patch disables [1002:6611] in radeon and enables it in amdgpu.
Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/1117
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
include/drm/drm_pciids.h| 1 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8ea86ffdea0d..1ad6f13a5bc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1017,6 +1017,15 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static struct drm_driver kms_driver;
+static void amdgpu_pci_fixup(struct pci_dev *pdev)
+{
+#ifdef CONFIG_DRM_AMDGPU_SI
+ /* [1002:6611] is disabled in radeon, so enable si_support in amdgpu. */
+ if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x6611)
+ amdgpu_si_support = 1;
+#endif
+}
+
static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1036,6 +1045,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ amdgpu_pci_fixup(pdev);
+
#ifdef CONFIG_DRM_AMDGPU_SI
if (!amdgpu_si_support) {
switch (flags & AMD_ASIC_MASK) {
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index b7e899ce44f0..57368a0f5b82 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -171,7 +171,6 @@
{0x1002, 0x6607, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6608, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
2.26.2
[PATCH] PCI/MSI: Fix restoring of MSI-X vector control's mask bit
MSI-X vector control's bit 0 is the mask bit, which masks the
corresponding interrupt request, or not. Other reserved bits might be
used for other purpose by device vendors. For example, the values of
Kingston NVMe SSD's MSI-X vector control are neither 0, nor 1, but other
values [1].
The original restoring logic in system resuming uses the whole MSI-X
vector control value as the flag to set/clear the mask bit. However,
this logic conflicts the idea mentioned above. It may mislead system to
disable the MSI-X vector entries. That makes system get no interrupt
from Kingston NVMe SSD after resume and usually get NVMe I/O timeout
error.
[ 174.715534] nvme nvme0: I/O 978 QID 3 timeout, completion polled
This patch takes only the mask bit of original MSI-X vector control
value as the flag to fix this issue.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=204887#c8
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Fixed: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Jian-Hong Pan
---
drivers/pci/msi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0884bedcfc7a..deae3d5acaf6 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -433,6 +433,7 @@ static void __pci_restore_msi_state(struct pci_dev *dev)
static void __pci_restore_msix_state(struct pci_dev *dev)
{
struct msi_desc *entry;
+ u32 flag;
if (!dev->msix_enabled)
return;
@@ -444,8 +445,10 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
PCI_MSIX_FLAGS_ENABLE | PCI_MSIX_FLAGS_MASKALL);
arch_restore_msi_irqs(dev);
- for_each_pci_msi_entry(entry, dev)
- msix_mask_irq(entry, entry->masked);
+ for_each_pci_msi_entry(entry, dev) {
+ flag = entry->masked & PCI_MSIX_ENTRY_CTRL_MASKBIT;
+ msix_mask_irq(entry, flag);
+ }
pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
}
--
2.23.0
[PATCH] nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T
Kingston NVME SSD with firmware version E8FK11.T has no interrupt after
resume with actions related to suspend to idle. This patch applied
NVME_QUIRK_SIMPLE_SUSPEND quirk to fix this issue.
Fixes: d916b1be94b6 ("nvme-pci: use host managed power state for suspend")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204887
Signed-off-by: Jian-Hong Pan
---
drivers/nvme/host/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 1ede1763a5ee..84fe3c4059a2 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2298,6 +2298,16 @@ static const struct nvme_core_quirk_entry core_quirks[]
= {
.vid = 0x14a4,
.fr = "2230",
.quirks = NVME_QUIRK_SIMPLE_SUSPEND,
+ },
+ {
+ /*
+* This Kingston E8FK11.T firmware version has no interrupt
+* after resume with actions related to suspend to idle
+* https://bugzilla.kernel.org/show_bug.cgi?id=204887
+*/
+ .vid = 0x2646,
+ .fr = "E8FK11.T",
+ .quirks = NVME_QUIRK_SIMPLE_SUSPEND,
}
};
--
2.20.1
[PATCH] Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices
The ASUS X412FA laptop contains a Realtek RTL8822CE device with an
associated BT chip using a USB ID of 04ca:4005. This ID is added to the
driver.
The /sys/kernel/debug/usb/devices portion for this device is:
T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=4005 Rev= 0.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c01
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707
Signed-off-by: Jian-Hong Pan
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5cf0734eb31b..67c0ca9b1f63 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -384,6 +384,9 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3526), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x0b05, 0x185c), .driver_info = BTUSB_REALTEK },
+ /* Additional Realtek 8822CE Bluetooth devices */
+ { USB_DEVICE(0x04ca, 0x4005), .driver_info = BTUSB_REALTEK },
+
/* Silicon Wave based devices */
{ USB_DEVICE(0x0c10, 0x), .driver_info = BTUSB_SWAVE },
--
2.20.1
Re: [PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Takashi Iwai 於 2019年9月2日 週一 下午7:41寫道：
>
> On Mon, 02 Sep 2019 12:00:56 +0200,
> Jian-Hong Pan wrote:
> >
> > Original pin node values of ASUS UX431FL with ALC294:
> >
> > 0x12 0xb7a60140
> > 0x13 0x4000
> > 0x14 0x90170110
> > 0x15 0x41f0
> > 0x16 0x41f0
> > 0x17 0x90170111
> > 0x18 0x41f0
> > 0x19 0x41f0
> > 0x1a 0x41f0
> > 0x1b 0x41f0
> > 0x1d 0x4066852d
> > 0x1e 0x41f0
> > 0x1f 0x41f0
> > 0x21 0x04211020
> >
> > 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
> >route become confused. So, the output volume cannot be changed by
> >setting.
> > 2. Misses the headset mic pin node.
> >
> > This patch disables the confusing speaker (NID 0x14) and enables the
> > headset mic (NID 0x19).
>
> Is 0x14 really a dead pin? Or is a surround/bass speaker or such?
I checked Windows (updated to latest and including Realtek MEDIA) on
ASUS UX431FL laptop again. Although it has two internal speaker pins,
there is only one set of internal speaker including left/right
channels. And the audio test (Speaker Setup) only shows left/right
channels. So, NID 0x14 can be disabled.
Jain-Hong Pan
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > sound/pci/hda/patch_realtek.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index e333b3e30e31..0a1fa99a6723 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5797,6 +5797,7 @@ enum {
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> > ALC299_FIXUP_PREDATOR_SPK,
> > + ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -6837,6 +6838,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > { }
> > }
> > },
> > + [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_PINS,
> > + .v.pins = (const struct hda_pintbl[]) {
> > + { 0x14, 0x41f0 }, /* disable confusing internal
> > speaker */
> > + { 0x19, 0x04a11150 }, /* use as headset mic, without
> > its own jack detect */
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -6995,6 +7006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
> > ALC269VB_FIXUP_ASUS_ZENBOOK),
> > SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
> > ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> > SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> > + SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL",
> > ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
> > SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
> > SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
> > --
> > 2.20.1
> >
> >
Re: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Kalle Valo 於 2019年9月2日 週一 下午8:18寫道： > > Tony Chuang writes: > > >> From: Jian-Hong Pan > >> Subject: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ > >> > >> There is a mass of jobs between spin lock and unlock in the hardware > >> IRQ which will occupy much time originally. To make system work more > >> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to > >> reduce the time in hardware IRQ. > >> > >> Signed-off-by: Jian-Hong Pan > > > > Now it works fine with MSI interrupt enabled. > > > > But this patch is conflicting with MSI interrupt patch. > > Is there a better way we can make Kalle apply them more smoothly? > > I can rebase them and submit both if you're OK. The rebase work is appreciated. Thank you, Jian-Hong Pan > Yeah, submitting all the MSI patches in the same patchset is the easiest > approach. That way they apply cleanly to wireless-drivers-next. > > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Original pin node values of ASUS UX431FL with ALC294:
0x12 0xb7a60140
0x13 0x4000
0x14 0x90170110
0x15 0x41f0
0x16 0x41f0
0x17 0x90170111
0x18 0x41f0
0x19 0x41f0
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x4066852d
0x1e 0x41f0
0x1f 0x41f0
0x21 0x04211020
1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
route become confused. So, the output volume cannot be changed by
setting.
2. Misses the headset mic pin node.
This patch disables the confusing speaker (NID 0x14) and enables the
headset mic (NID 0x19).
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e333b3e30e31..0a1fa99a6723 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5797,6 +5797,7 @@ enum {
ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC299_FIXUP_PREDATOR_SPK,
+ ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6837,6 +6838,16 @@ static const struct hda_fixup alc269_fixups[] = {
{ }
}
},
+ [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x14, 0x41f0 }, /* disable confusing internal
speaker */
+ { 0x19, 0x04a11150 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6995,6 +7006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
+ SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL",
ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
--
2.20.1
Re: [PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月21日 週三 下午4:16寫道：
>
> Hi,
>
> > From: Jian-Hong Pan [mailto:jian-h...@endlessm.com]
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > v3:
> > Extend the spin lock protecting area for the TX path in
> > rtw_pci_interrupt_threadfn by Realtek's suggestion
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..a8c17a01f318 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(>irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
> > +out:
> > + spin_unlock(>irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > + spin_lock_irqsave(>irq_lock, flags);
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(>irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> > + rtw_pci_enable_interrupt(rtwdev, rtwpci);
>
> I've applied this patch and tested it.
> But I failed to connect to AP, it seems that the
> scan_result is empty. And when I failed to connect
> to the AP, I found that the IMR is not enabled.
> I guess the check bypass the interrupt enable function.
>
> And I also found that *without MSI*, the driver is
> able to connect to the AP. Could you please verify
> this patch again with MSI interrupt enabled and
> send a v4?
>
> You can find my MSI patch on
> https://patchwork.kernel.org/patch/11081539/
I have just sent v4 patch. Also tested the modified MSI patch like below:
The WiFi works fine on ASUS X512DK (including MSI enabled).
Jian-Hong Pan
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 955dd6c6fb57..d18f5aae1585 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -11,6 +11,10 @@
#include "fw.h"
#include "debug.h"
+static bool rtw_disable_msi;
+module_param_named(disable_msi, rtw_disable_msi, bool, 0644);
+MODULE_PARM_DESC(disable_msi, "Set Y to disable MSI interrupt support");
+
static u32 rtw_pci_tx_queue_idx_addr[] = {
[RTW_TX_QUEUE_BK]= RTK_PCI_TXBD_IDX_BKQ,
[RTW_TX_QUEUE_BE]= RTK_PCI_TXBD_IDX_BEQ,
@@ -1116,6 +1120,48 @@ static struct rtw_hci_ops rtw_pci_ops = {
.write_data_h2c = rtw_pci_write_data_h2c,
};
+static int rtw_pci_request_irq(struct rtw_dev *rtwdev, struct pci_dev *pdev)
+{
+struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+int ret;
+
+if (!rtw_disable_msi) {
+ret = pci_enable_msi(pdev);
+if (ret) {
+rtw_warn(rtwdev, "failed to enable msi %d, using legacy irq\n",
+ ret);
+} else {
+rtw_warn(rtwdev, "pci msi enabled\n");
+rtwpci->msi_enabled = true;
+}
+}
[PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
v4:
Remove the WiFi running check in rtw_pci_interrupt_threadfn to avoid AP
connection failed by Realtek's suggestion.
drivers/net/wireless/realtek/rtw88/pci.c | 32 +++-
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..955dd6c6fb57 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(>irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(>irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(>irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,9 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(>irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(>irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1170,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, _pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1212,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
[PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..a8c17a01f318 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(>irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(>irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(>irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(>irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(>irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, _pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午6:44寫道：
>
> > From: Jian-Hong Pan
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..0740140d7e46 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(>irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
> So basically it's to prevent back-to-back interrupts.
>
> Nothing wrong about it, I just wondering why we don't like
> back-to-back interrupts. Does it means that those interrupts
> fired between irq_handler and threadfin would increase
> much more time to consume them.
1. It is one of the reasons. Besides, the hardware interrupt has
higher priority than soft IRQ. If next hardware interrupt is coming
faster then the soft IRQ (BH), the software IRQ may always become
pended.
2. Keep the data's state until the interrupt is fully dealt.
3. The process of request_threaded_irq is documented:
https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html
> > +out:
> > + spin_unlock(>irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(>irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + spin_lock_irqsave(>irq_lock, flags);
>
> I suggest to protect the ISRs. Because next patches will require
> to check if the TX DMA path is empty. This means I will also add
> this rtwpci->irq_lock to the TX path, and check if the skb_queue
> does not have any pending SKBs not DMAed successfully.
Ah ... Okay for the TX path
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
>
> Why check the flag here? Is there any racing or something?
> Otherwise it looks to break the symmetry.
According to backtrace, I notice rtw_pci_stop will be invoked in
rtw_power_off, rtw_core_stop which clears the running state.
rtw_core_stop is invoked by rtw_enter_ips due to IEEE80211_CONF_IDLE.
If the stop command comes between the hardware interrupt and soft IRQ
(BH) and there is no start command again, I think user wants the WiFi
stop instead of becoming start again.
Jian-Hong Pan
[PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..0740140d7e46 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(>irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(>irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(>irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ spin_lock_irqsave(>irq_lock, flags);
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(>irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, _pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午4:07寫道：
>
> Hi,
>
> A few more questions below
>
> > > From: Jian-Hong Pan [mailto:jian-h...@endlessm.com]
> > >
> > > There is a mass of jobs between spin lock and unlock in the hardware
> > > IRQ which will occupy much time originally. To make system work more
> > > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > > reduce the time in hardware IRQ.
> > >
> > > Signed-off-by: Jian-Hong Pan
> > > ---
> > > drivers/net/wireless/realtek/rtw88/pci.c | 36 +++-
> > > 1 file changed, 29 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > > b/drivers/net/wireless/realtek/rtw88/pci.c
> > > index 00ef229552d5..355606b167c6 100644
> > > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > > @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> > irq,
> > > void *dev)
> > > {
> > > struct rtw_dev *rtwdev = dev;
> > > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > > - u32 irq_status[4];
> > > + unsigned long flags;
> > >
> > > - spin_lock(>irq_lock);
> > > + spin_lock_irqsave(>irq_lock, flags);
>
> I think you can use 'spin_lock()' here as it's in IRQ context?
Ah! You are right! The interrupts are already disabled in the
interrupt handler. So, there is no need to disable more once. I can
tweak it.
> > > if (!rtwpci->irq_enabled)
> > > goto out;
> > >
> > > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > > of
> > > +* thread function
> > > +*/
> > > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
>
> Why do we need rtw_pci_disable_interrupt() here.
> Have you done any experiment and decided to add this.
> If you have can you share your results to me?
I got this idea "Avoid back to back interrupt" from Intel WiFi's driver.
https://elixir.bootlin.com/linux/v5.3-rc4/source/drivers/net/wireless/intel/iwlwifi/pcie/rx.c#L2071
So, I disable rtw_pci interrupt here in first half IRQ. (Re-enable in
bottom half)
>
> > > +out:
> > > + spin_unlock_irqrestore(>irq_lock, flags);
>
> spin_unlock()
>
> > > +
> > > + return IRQ_WAKE_THREAD;
> > > +}
> > > +
> > > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > > +{
> > > + struct rtw_dev *rtwdev = dev;
> > > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > > + unsigned long flags;
> > > + u32 irq_status[4];
> > > +
> > > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> > >
> > > if (irq_status[0] & IMR_MGNTDOK)
> > > @@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> > irq,
> > > void *dev)
> > > if (irq_status[0] & IMR_ROK)
> > > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> > >
> > > -out:
> > > - spin_unlock(>irq_lock);
> > > + /* all of the jobs for this interrupt have been done */
> > > + spin_lock_irqsave(>irq_lock, flags);
> >
> > Shouldn't we protect the ISRs above?
> >
> > This patch could actually reduce the time of IRQ.
> > But I think I need to further test it with PCI MSI interrupt.
> > https://patchwork.kernel.org/patch/11081539/
> >
> > Maybe we could drop the "rtw_pci_[enable/disable]_interrupt" when MSI
> > Is enabled with this patch.
> >
> > > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> > > + rtw_pci_enable_interrupt(rtwdev, rtwpci);
Then, re-enable rtw_pci interrupt here in bottom half of the IRQ.
Here is the place where Intel WiFi re-enable interrupts.
https://elixir.bootlin.com/linux/v5.3-rc4/source/drivers/net/wireless/intel/iwlwifi/pcie/rx.c#L1959
Now, we can go back to the question "Shouldn't we protect the ISRs above?"
1. What does the lock: rtwpci->irq_lock protect for?
According to the code, seems only rtw_pci interrupt's state which is
enabled or not.
2. How about the ISRs you mentioned?
This part will only be executed if there is a fresh rtw_pci interrupt.
The first half already disabled rtw_pci interrupt, so there is no more
fresh rtw_pci interrupt until rtw_pci interrupt is enabled again.
Therefor, the rtwpci->irq_lock only wraps the rtw_pci interrupt
enablement.
If there is any more entry that I missed and will interfere, please let me know.
Thank you
Jian-Hong Pan
[PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan
---
drivers/net/wireless/realtek/rtw88/pci.c | 36 +++-
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..355606b167c6 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
+ unsigned long flags;
- spin_lock(>irq_lock);
+ spin_lock_irqsave(>irq_lock, flags);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+* thread function
+*/
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock_irqrestore(>irq_lock, flags);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void
*dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(>irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ spin_lock_irqsave(>irq_lock, flags);
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(>irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1172,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, _pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1214,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
David Laight 於 2019年7月26日 週五 下午5:23寫道： > > From: Jian-Hong Pan > > Sent: 26 July 2019 07:18 > ... > > > While allocating all 512 buffers in one block (just over 4MB) > > > is probably not a good idea, you may need to allocated (and dma map) > > > then in groups. > > > > Thanks for reviewing. But got questions here to double confirm the idea. > > According to original code, it allocates 512 skbs for RX ring and dma > > mapping one by one. So, the new code allocates memory buffer 512 > > times to get 512 buffer arrays. Will the 512 buffers arrays be in one > > block? Do you mean aggregate the buffers as a scatterlist and use > > dma_map_sg? > > If you malloc a buffer of size (8192+32) the allocator will either > round it up to a whole number of (often 4k) pages or to a power of > 2 of pages - so either 12k of 16k. > I think the Linux allocator does the latter. > Some of the allocators also 'steal' a bit from the front of the buffer > for 'red tape'. > > OTOH malloc the space 15 buffers and the allocator will round the > 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the > buffers. > > You then dma_map the large buffer and split into the actual rx buffers. > Repeat until you've filled the entire ring. > The only complication is remembering the base address (and size) for > the dma_unmap and free. > Although there is plenty of padding to extend the buffer structure > significantly without using more memory. > Allocate in 15's and you (probably) have 512 bytes per buffer. > Allocate in 31's and you have 256 bytes. > > The problem is that larger allocates are more likely to fail > (especially if the system has been running for some time). > So you almost certainly want to be able to fall back to smaller > allocates even though they use more memory. > > I also wonder if you actually need 512 8k rx buffers to cover > interrupt latency? > I've not done any measurements for 20 years! Thanks for the explanation. I am not sure the combination of 512 8k RX buffers. Maybe Realtek folks can give us some idea. Tony Chuang any comment? Jian-Hong Pan
Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
David Laight 於 2019年7月25日 週四 下午5:21寫道：
>
> From: Jian-Hong Pan
> > Sent: 25 July 2019 09:09
> > Each skb as the element in RX ring was expected with sized buffer 8216
> > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> > 16640 bytes for alignment after allocated, x86_64 for example. And, the
> > difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
> > To prevent that much wasted memory, this patch follows David's
> > suggestion [1] and uses general buffer arrays, instead of skbs as the
> > elements in RX ring.
> ...
> > for (i = 0; i < len; i++) {
> > - skb = dev_alloc_skb(buf_sz);
> > - if (!skb) {
> > + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
>
> You should do this allocation somewhere than can sleep.
> So you don't need GFP_ATOMIC, making the allocate (and dma map)
> much less likely to fail.
> If they do fail using a smaller ring might be better than failing
> completely.
Ok, I can tweak and try it.
> I suspect that buf_sz gets rounded up somewhat.
> Also you almost certainly want 'buf' to be cache-line aligned.
> I don't think devm_kzalloc() guarantees that at all.
Sure
> While allocating all 512 buffers in one block (just over 4MB)
> is probably not a good idea, you may need to allocated (and dma map)
> then in groups.
Thanks for reviewing. But got questions here to double confirm the idea.
According to original code, it allocates 512 skbs for RX ring and dma
mapping one by one. So, the new code allocates memory buffer 512
times to get 512 buffer arrays. Will the 512 buffers arrays be in one
block? Do you mean aggregate the buffers as a scatterlist and use
dma_map_sg?
Thank you,
Jain-Hong Pan
[PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
Each skb as the element in RX ring was expected with sized buffer 8216
(RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
16640 bytes for alignment after allocated, x86_64 for example. And, the
difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
To prevent that much wasted memory, this patch follows David's
suggestion [1] and uses general buffer arrays, instead of skbs as the
elements in RX ring.
[1] https://www.spinics.net/lists/linux-wireless/msg187870.html
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 132 +--
drivers/net/wireless/realtek/rtw88/pci.h | 2 +-
2 files changed, 75 insertions(+), 59 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06afef3d..e953010f0179 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -111,25 +111,49 @@ static void rtw_pci_free_tx_ring(struct rtw_dev *rtwdev,
tx_ring->r.head = NULL;
}
+static struct rtw_pci_rx_buffer_desc *rtw_pci_get_rx_desc(
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ u32 desc_sz = rx_ring->r.desc_size;
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+idx * desc_sz);
+ return buf_desc;
+}
+
+static dma_addr_t rtw_pci_get_rx_bufdma(struct rtw_pci_rx_ring *rx_ring,
+ u32 idx)
+{
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ dma_addr_t dma;
+
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
+ dma = le32_to_cpu(buf_desc->dma);
+
+ return dma;
+}
+
static void rtw_pci_free_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
- struct sk_buff *skb;
+ u8 *buf;
dma_addr_t dma;
u8 *head = rx_ring->r.head;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
int ring_sz = rx_ring->r.desc_size * rx_ring->r.len;
- int i;
+ u32 i;
for (i = 0; i < rx_ring->r.len; i++) {
- skb = rx_ring->buf[i];
- if (!skb)
+ buf = rx_ring->buf[i];
+ if (!buf)
continue;
- dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE);
- dev_kfree_skb(skb);
+ dma = rtw_pci_get_rx_bufdma(rx_ring, i);
+ pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE);
+ devm_kfree(rtwdev->dev, buf);
rx_ring->buf[i] = NULL;
}
@@ -180,27 +204,24 @@ static int rtw_pci_init_tx_ring(struct rtw_dev *rtwdev,
return 0;
}
-static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb,
-struct rtw_pci_rx_ring *rx_ring,
-u32 idx, u32 desc_sz)
+static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, u8 *buf,
+struct rtw_pci_rx_ring *rx_ring, u32 idx)
{
struct pci_dev *pdev = to_pci_dev(rtwdev->dev);
struct rtw_pci_rx_buffer_desc *buf_desc;
int buf_sz = RTK_PCI_RX_BUF_SIZE;
dma_addr_t dma;
- if (!skb)
+ if (!buf)
return -EINVAL;
- dma = pci_map_single(pdev, skb->data, buf_sz, PCI_DMA_FROMDEVICE);
+ dma = pci_map_single(pdev, buf, buf_sz, DMA_FROM_DEVICE);
if (pci_dma_mapping_error(pdev, dma))
return -EBUSY;
- *((dma_addr_t *)skb->cb) = dma;
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
-idx * desc_sz);
- memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc = rtw_pci_get_rx_desc(rx_ring, idx);
buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->total_pkt_size = cpu_to_le16(0);
buf_desc->dma = cpu_to_le32(dma);
return 0;
@@ -208,7 +229,7 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
struct sk_buff *skb,
static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
struct rtw_pci_rx_ring *rx_ring,
- u32 idx, u32 desc_sz)
+ u32 idx)
{
struct device *dev = rtwdev->dev;
struct rtw_pci_rx_buffer_desc *buf_desc;
@@ -216,10 +237,9 @@ static void rtw_pci_sync_rx_desc_device(struct rtw_dev
*rtwdev, dma_addr_t dma,
dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
- buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.h
Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Jian-Hong Pan 於 2019年7月11日 週四 下午1:28寫道：
>
> Jian-Hong Pan 於 2019年7月11日 週四 下午1:25寫道：
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
> >
> > rx routine starvation
> > WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
> > rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> > [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> >
> > Then we see a variety of different error conditions and kernel panics,
> > such as this one (trimmed):
> >
> > rtw_pci :02:00.0: pci bus timeout, check dma status
> > skbuff: skb_over_panic: text:091b6e66 len:415 put:415
> > head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
> > [ cut here ]
> > kernel BUG at net/core/skbuff.c:105!
> > invalid opcode: [#1] SMP NOPTI
> > RIP: 0010:skb_panic+0x43/0x45
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new, data-sized skb first in RX ISR. After
> > copying the data in, we pass it to the upper layers. However, if skb
> > allocation fails, we effectively drop the frame. In both cases, the
> > original, full size ring skb is reused.
> >
> > In addition, to fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan
> > Cc:
> > ---
>
> Sorry, I forget to place the version difference here.
>
> v2:
> - Allocate new data-sized skb and put data into it, then pass it to
>mac80211. Reuse the original skb in RX ring by DMA sync.
> - Modify the commit message.
> - Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
>of remapping in RX ISR.
>
> v3:
> - Same as v2.
>
> v4:
> - Fix comment: allocate a new skb for this frame, discard the frame
> if none available
>
> > drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..c415f5e94fed 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > u32 pkt_offset;
> > u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> > u32 buf_desc_sz = chip->rx_buf_desc_sz;
> > + u32 new_len;
> > u8 *rx_desc;
> > dma_addr_t dma;
> >
> > @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> > pkt_stat.shift;
> >
> > - if (pkt_stat.is_c2h) {
> > - /* keep rx_desc, halmac needs it */
> > - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> > + /* allocate a new skb for this frame,
> > +* discard the frame if none available
> > +*/
> > + new_len = pkt_stat.pkt_len + pkt_offset;
> > + new = dev_alloc_skb(new_len);
> > + if (WARN_ONCE(!new, "rx routine starvation\n"))
> > + goto next_rp;
> > +
> > + /* put the DMA data including rx_desc from phy to new skb */
> > + skb_put_data(new, skb->data, new_len);
> >
> > - /* pass offset for further operation */
> > - *((u32 *)skb->cb) = pkt_offset;
> > - skb_queue_tail(>c2h_queue, skb);
> > + if (pkt_stat.is_c2h) {
> > +/* pass rx_desc & offset for further operation */
> > + *((u32 *)new->cb) = pkt_offset;
> > + skb_queue_tail(>c2h_queue, new);
> >
Re: [PATCH v4 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
Jian-Hong Pan 於 2019年7月11日 週四 下午1:25寫道：
>
> Since each skb in RX ring is reused instead of new allocation, we can
> treat the DMA in a more efficient way by DMA synchronization.
>
> Signed-off-by: Jian-Hong Pan
> Cc:
> ---
Sorry, also forget to place the version difference here
v2:
- New patch by following [PATCH v3 1/2] rtw88: pci: Rearrange the
memory usage for skb in RX ISR.
v3:
- Remove rtw_pci_sync_rx_desc_cpu and call dma_sync_single_for_cpu in
rtw_pci_rx_isr directly.
- Remove the return value of rtw_pci_sync_rx_desc_device.
- Use DMA_FROM_DEVICE instead of PCI_DMA_FROMDEVICE.
v4:
- Same as v3.
> drivers/net/wireless/realtek/rtw88/pci.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index c415f5e94fed..68fae52151dd 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -206,6 +206,23 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
> struct sk_buff *skb,
> return 0;
> }
>
> +static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t
> dma,
> + struct rtw_pci_rx_ring *rx_ring,
> + u32 idx, u32 desc_sz)
> +{
> + struct device *dev = rtwdev->dev;
> + struct rtw_pci_rx_buffer_desc *buf_desc;
> + int buf_sz = RTK_PCI_RX_BUF_SIZE;
> +
> + dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
> +
> + buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
> +idx * desc_sz);
> + memset(buf_desc, 0, sizeof(*buf_desc));
> + buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
> + buf_desc->dma = cpu_to_le32(dma);
> +}
> +
> static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
> struct rtw_pci_rx_ring *rx_ring,
> u8 desc_size, u32 len)
> @@ -782,8 +799,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
> rtw_pci *rtwpci,
> rtw_pci_dma_check(rtwdev, ring, cur_rp);
> skb = ring->buf[cur_rp];
> dma = *((dma_addr_t *)skb->cb);
> - pci_unmap_single(rtwpci->pdev, dma, RTK_PCI_RX_BUF_SIZE,
> -PCI_DMA_FROMDEVICE);
> + dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE,
> + DMA_FROM_DEVICE);
> rx_desc = skb->data;
> chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
> _status);
>
> @@ -818,7 +835,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
> rtw_pci *rtwpci,
>
> next_rp:
> /* new skb delivered to mac80211, re-enable original skb DMA
> */
> - rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
> + rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
> + buf_desc_sz);
>
> /* host read next element in ring */
> if (++cur_rp >= ring->r.len)
> --
> 2.22.0
>
Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Jian-Hong Pan 於 2019年7月11日 週四 下午1:25寫道：
>
> Testing with RTL8822BE hardware, when available memory is low, we
> frequently see a kernel panic and system freeze.
>
> First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
>
> rx routine starvation
> WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
> rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
>
> Then we see a variety of different error conditions and kernel panics,
> such as this one (trimmed):
>
> rtw_pci :02:00.0: pci bus timeout, check dma status
> skbuff: skb_over_panic: text:091b6e66 len:415 put:415
> head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
> [ cut here ]
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode: [#1] SMP NOPTI
> RIP: 0010:skb_panic+0x43/0x45
>
> When skb allocation fails and the "rx routine starvation" is hit, the
> function returns immediately without updating the RX ring. At this
> point, the RX ring may continue referencing an old skb which was already
> handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> bad things happen.
>
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, to fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan
> Cc:
> ---
Sorry, I forget to place the version difference here.
v2:
- Allocate new data-sized skb and put data into it, then pass it to
mac80211. Reuse the original skb in RX ring by DMA sync.
- Modify the commit message.
- Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
of remapping in RX ISR.
v3:
- Same as v2.
v4:
- Fix comment: allocate a new skb for this frame, discard the frame
if none available
> drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
> 1 file changed, 22 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index cfe05ba7280d..c415f5e94fed 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
> rtw_pci *rtwpci,
> u32 pkt_offset;
> u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> u32 buf_desc_sz = chip->rx_buf_desc_sz;
> + u32 new_len;
> u8 *rx_desc;
> dma_addr_t dma;
>
> @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> struct rtw_pci *rtwpci,
> pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> pkt_stat.shift;
>
> - if (pkt_stat.is_c2h) {
> - /* keep rx_desc, halmac needs it */
> - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> + /* allocate a new skb for this frame,
> +* discard the frame if none available
> +*/
> + new_len = pkt_stat.pkt_len + pkt_offset;
> + new = dev_alloc_skb(new_len);
> + if (WARN_ONCE(!new, "rx routine starvation\n"))
> + goto next_rp;
> +
> + /* put the DMA data including rx_desc from phy to new skb */
> + skb_put_data(new, skb->data, new_len);
>
> - /* pass offset for further operation */
> - *((u32 *)skb->cb) = pkt_offset;
> - skb_queue_tail(>c2h_queue, skb);
> + if (pkt_stat.is_c2h) {
> +/* pass rx_desc & offset for further operation */
> + *((u32 *)new->cb) = pkt_offset;
> + skb_queue_tail(>c2h_queue, new);
> ieee80211_queue_work(rtwdev->hw, >c2h_work);
> } else {
> - /* remove rx_desc, maybe use skb_pull? */
> - skb_put(skb, pkt_stat.pkt_len);
> - skb_reserve(skb, pkt_offset);
> -
> - /* alloc a smaller skb to mac80211 */
> - new = dev_alloc_skb(pkt_stat.pkt_len);
> - if (!new) {
> - new = skb;
> -
[PATCH v4 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index c415f5e94fed..68fae52151dd 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -206,6 +206,23 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
struct sk_buff *skb,
return 0;
}
+static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx, u32 desc_sz)
+{
+ struct device *dev = rtwdev->dev;
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ int buf_sz = RTK_PCI_RX_BUF_SIZE;
+
+ dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+idx * desc_sz);
+ memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->dma = cpu_to_le32(dma);
+}
+
static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring,
u8 desc_size, u32 len)
@@ -782,8 +799,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
rtw_pci_dma_check(rtwdev, ring, cur_rp);
skb = ring->buf[cur_rp];
dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(rtwpci->pdev, dma, RTK_PCI_RX_BUF_SIZE,
-PCI_DMA_FROMDEVICE);
+ dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE,
+ DMA_FROM_DEVICE);
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
_status);
@@ -818,7 +835,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
next_rp:
/* new skb delivered to mac80211, re-enable original skb DMA */
- rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
+ rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
+ buf_desc_sz);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
--
2.22.0
[PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
[ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci :02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:091b6e66 len:415 put:415
head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
[ cut here ]
kernel BUG at net/core/skbuff.c:105!
invalid opcode: [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new, data-sized skb first in RX ISR. After
copying the data in, we pass it to the upper layers. However, if skb
allocation fails, we effectively drop the frame. In both cases, the
original, full size ring skb is reused.
In addition, to fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..c415f5e94fed 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
u32 pkt_offset;
u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
u32 buf_desc_sz = chip->rx_buf_desc_sz;
+ u32 new_len;
u8 *rx_desc;
dma_addr_t dma;
@@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
pkt_stat.shift;
- if (pkt_stat.is_c2h) {
- /* keep rx_desc, halmac needs it */
- skb_put(skb, pkt_stat.pkt_len + pkt_offset);
+ /* allocate a new skb for this frame,
+* discard the frame if none available
+*/
+ new_len = pkt_stat.pkt_len + pkt_offset;
+ new = dev_alloc_skb(new_len);
+ if (WARN_ONCE(!new, "rx routine starvation\n"))
+ goto next_rp;
+
+ /* put the DMA data including rx_desc from phy to new skb */
+ skb_put_data(new, skb->data, new_len);
- /* pass offset for further operation */
- *((u32 *)skb->cb) = pkt_offset;
- skb_queue_tail(>c2h_queue, skb);
+ if (pkt_stat.is_c2h) {
+/* pass rx_desc & offset for further operation */
+ *((u32 *)new->cb) = pkt_offset;
+ skb_queue_tail(>c2h_queue, new);
ieee80211_queue_work(rtwdev->hw, >c2h_work);
} else {
- /* remove rx_desc, maybe use skb_pull? */
- skb_put(skb, pkt_stat.pkt_len);
- skb_reserve(skb, pkt_offset);
-
- /* alloc a smaller skb to mac80211 */
- new = dev_alloc_skb(pkt_stat.pkt_len);
- if (!new) {
- new = skb;
- } else {
- skb_put_data(new, skb->data, skb->len);
- dev_kfree_skb_any(skb);
- }
- /* TODO: merge into rx.c */
- rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
+ /* remove rx_desc */
+ skb_pull(new, pkt_offset);
+
+ rtw_rx_stats(rtwdev, pkt_stat.vif, new);
memcpy(new->cb, _status, sizeof(rx_status));
ieee80211_rx_irqsafe(rtwdev->hw, new);
}
- /* skb delivered to mac80211, alloc a new one in rx ring */
- new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
- if (WARN(!new, "rx routine starvation\n"))
- return;
-
- ring->buf[cur_rp] = new;
- rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_
Re: [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
David Laight 於 2019年7月10日 週三 下午4:57寫道：
>
> From: Jian-Hong Pan
> > Sent: 10 July 2019 09:38
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
> >
> > rx routine starvation
> > WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
> > rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> > [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> >
> > Then we see a variety of different error conditions and kernel panics,
> > such as this one (trimmed):
> >
> > rtw_pci :02:00.0: pci bus timeout, check dma status
> > skbuff: skb_over_panic: text:091b6e66 len:415 put:415
> > head:d2880c6f
> > data:7a02b1ea tail:0x1df end:0xc0 dev:
> > [ cut here ]
> > kernel BUG at net/core/skbuff.c:105!
> > invalid opcode: [#1] SMP NOPTI
> > RIP: 0010:skb_panic+0x43/0x45
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new, data-sized skb first in RX ISR. After
> > copying the data in, we pass it to the upper layers. However, if skb
> > allocation fails, we effectively drop the frame. In both cases, the
> > original, full size ring skb is reused.
> >
> > In addition, by fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
>
> A couple of minor nits (see below).
> You may want to do a followup patch that changes the rx buffers
> (used by the hardware) to by just memory buffers.
> Nothing (probably) relies on them being skb with all the accociated
> baggage.
It is a good idea for later commit.
> David
>
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan
> > Cc:
> > ---
> > v2:
> > - Allocate new data-sized skb and put data into it, then pass it to
> >mac80211. Reuse the original skb in RX ring by DMA sync.
> > - Modify the commit message.
> > - Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
> >of remapping in RX ISR.
> >
> > v3:
> > - Same as v2.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..e9fe3ad896c8 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > u32 pkt_offset;
> > u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> > u32 buf_desc_sz = chip->rx_buf_desc_sz;
> > + u32 new_len;
> > u8 *rx_desc;
> > dma_addr_t dma;
> >
> > @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> >pkt_stat.shift;
> >
> > - if (pkt_stat.is_c2h) {
> > - /* keep rx_desc, halmac needs it */
> > - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> > + /* discard current skb if the new skb cannot be allocated as a
> > + * new one in rx ring later
> > + */
>
> That comment isn't quite right.
> maybe: "Allocate a new skb for this frame, discard if none available"
Thanks! I will tweak it.
> > + new_len = pkt_stat.pkt_len + pkt_offset;
> > + new = dev_alloc_skb(new_len);
> > + if (WARN_ONCE(!new, "rx routine starvation\n"))
>
> I think you should count these??
Larry has a different idea here. [1]
I agree with Larry that just need to know not enough memory here.
[1] https://lkml.org/lkml/2019/7/8/1049
Jian-Hong Pan
> > + goto next_rp;
> > +
> > + /* put the DMA data including rx_desc from phy to new skb */
> > + skb_put_data(new, s
Re: [PATCH v2 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Tony Chuang 於 2019年7月10日 週三 下午4:37寫道：
>
> > Subject: [PATCH v2 1/2] rtw88: pci: Rearrange the memory usage for skb in
> > RX ISR
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
> >
> > rx routine starvation
> > WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
> > rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> > [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> >
> > Then we see a variety of different error conditions and kernel panics,
> > such as this one (trimmed):
> >
> > rtw_pci :02:00.0: pci bus timeout, check dma status
> > skbuff: skb_over_panic: text:091b6e66 len:415 put:415
> > head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0
> > dev:
> > [ cut here ]
> > kernel BUG at net/core/skbuff.c:105!
> > invalid opcode: [#1] SMP NOPTI
> > RIP: 0010:skb_panic+0x43/0x45
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new, data-sized skb first in RX ISR. After
> > copying the data in, we pass it to the upper layers. However, if skb
> > allocation fails, we effectively drop the frame. In both cases, the
> > original, full size ring skb is reused.
> >
> > In addition, to fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan
> > Cc:
> > ---
> > drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..e9fe3ad896c8 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > u32 pkt_offset;
> > u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
> > u32 buf_desc_sz = chip->rx_buf_desc_sz;
> > + u32 new_len;
> > u8 *rx_desc;
> > dma_addr_t dma;
> >
> > @@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> >pkt_stat.shift;
> >
> > - if (pkt_stat.is_c2h) {
> > - /* keep rx_desc, halmac needs it */
> > - skb_put(skb, pkt_stat.pkt_len + pkt_offset);
> > + /* discard current skb if the new skb cannot be allocated as a
> > + * new one in rx ring later
> > + */
> > + new_len = pkt_stat.pkt_len + pkt_offset;
> > + new = dev_alloc_skb(new_len);
> > + if (WARN_ONCE(!new, "rx routine starvation\n"))
> > + goto next_rp;
> > +
> > + /* put the DMA data including rx_desc from phy to new skb */
> > + skb_put_data(new, skb->data, new_len);
> >
> > - /* pass offset for further operation */
> > - *((u32 *)skb->cb) = pkt_offset;
> > - skb_queue_tail(>c2h_queue, skb);
> > + if (pkt_stat.is_c2h) {
> > + /* pass rx_desc & offset for further operation */
> > + *((u32 *)new->cb) = pkt_offset;
> > + skb_queue_tail(>c2h_queue, new);
> > ieee80211_queue_work(rtwdev->hw, >c2h_work);
> > } else {
> > - /* remove rx_desc, maybe use skb_pull? */
> > - skb_put(skb, pkt_stat.pkt_len);
> > - skb_reserve(skb, pkt_offset);
> > -
> > - /* alloc a smaller skb to mac80211 */
> > - new = dev_alloc_skb(pkt_stat.pkt_len);
> > -
[PATCH v3 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan
Cc:
---
v2:
- New patch by following [PATCH v3 1/2] rtw88: pci: Rearrange the
memory usage for skb in RX ISR.
v3:
- Remove rtw_pci_sync_rx_desc_cpu and call dma_sync_single_for_cpu in
rtw_pci_rx_isr directly.
- Remove the return value of rtw_pci_sync_rx_desc_device.
- Use DMA_FROM_DEVICE instead of PCI_DMA_FROMDEVICE.
drivers/net/wireless/realtek/rtw88/pci.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index e9fe3ad896c8..485d30c06935 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -206,6 +206,23 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
struct sk_buff *skb,
return 0;
}
+static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx, u32 desc_sz)
+{
+ struct device *dev = rtwdev->dev;
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ int buf_sz = RTK_PCI_RX_BUF_SIZE;
+
+ dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE);
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+idx * desc_sz);
+ memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->dma = cpu_to_le32(dma);
+}
+
static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring,
u8 desc_size, u32 len)
@@ -782,8 +799,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
rtw_pci_dma_check(rtwdev, ring, cur_rp);
skb = ring->buf[cur_rp];
dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(rtwpci->pdev, dma, RTK_PCI_RX_BUF_SIZE,
-PCI_DMA_FROMDEVICE);
+ dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE,
+ DMA_FROM_DEVICE);
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
_status);
@@ -818,7 +835,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
next_rp:
/* new skb delivered to mac80211, re-enable original skb DMA */
- rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
+ rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
+ buf_desc_sz);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
--
2.22.0
[PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
[ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci :02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:091b6e66 len:415 put:415
head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
[ cut here ]
kernel BUG at net/core/skbuff.c:105!
invalid opcode: [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new, data-sized skb first in RX ISR. After
copying the data in, we pass it to the upper layers. However, if skb
allocation fails, we effectively drop the frame. In both cases, the
original, full size ring skb is reused.
In addition, by fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
Signed-off-by: Jian-Hong Pan
Cc:
---
v2:
- Allocate new data-sized skb and put data into it, then pass it to
mac80211. Reuse the original skb in RX ring by DMA sync.
- Modify the commit message.
- Introduce following [PATCH v3 2/2] rtw88: pci: Use DMA sync instead
of remapping in RX ISR.
v3:
- Same as v2.
drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..e9fe3ad896c8 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
u32 pkt_offset;
u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
u32 buf_desc_sz = chip->rx_buf_desc_sz;
+ u32 new_len;
u8 *rx_desc;
dma_addr_t dma;
@@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
pkt_stat.shift;
- if (pkt_stat.is_c2h) {
- /* keep rx_desc, halmac needs it */
- skb_put(skb, pkt_stat.pkt_len + pkt_offset);
+ /* discard current skb if the new skb cannot be allocated as a
+* new one in rx ring later
+*/
+ new_len = pkt_stat.pkt_len + pkt_offset;
+ new = dev_alloc_skb(new_len);
+ if (WARN_ONCE(!new, "rx routine starvation\n"))
+ goto next_rp;
+
+ /* put the DMA data including rx_desc from phy to new skb */
+ skb_put_data(new, skb->data, new_len);
- /* pass offset for further operation */
- *((u32 *)skb->cb) = pkt_offset;
- skb_queue_tail(>c2h_queue, skb);
+ if (pkt_stat.is_c2h) {
+/* pass rx_desc & offset for further operation */
+ *((u32 *)new->cb) = pkt_offset;
+ skb_queue_tail(>c2h_queue, new);
ieee80211_queue_work(rtwdev->hw, >c2h_work);
} else {
- /* remove rx_desc, maybe use skb_pull? */
- skb_put(skb, pkt_stat.pkt_len);
- skb_reserve(skb, pkt_offset);
-
- /* alloc a smaller skb to mac80211 */
- new = dev_alloc_skb(pkt_stat.pkt_len);
- if (!new) {
- new = skb;
- } else {
- skb_put_data(new, skb->data, skb->len);
- dev_kfree_skb_any(skb);
- }
- /* TODO: merge into rx.c */
- rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
+ /* remove rx_desc */
+ skb_pull(new, pkt_offset);
+
+ rtw_rx_stats(rtwdev, pkt_stat.vif, new);
memcpy(new->cb, _status, sizeof(rx_status));
ieee80211_rx_irqsafe(rtwdev->hw, new);
}
- /* skb delivered to mac80211, al
[PATCH v2 2/2] rtw88: pci: Use DMA sync instead of remapping in RX ISR
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan
---
drivers/net/wireless/realtek/rtw88/pci.c | 35 ++--
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index e9fe3ad896c8..28ca76f71dfe 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -206,6 +206,35 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev,
struct sk_buff *skb,
return 0;
}
+static int rtw_pci_sync_rx_desc_cpu(struct rtw_dev *rtwdev, dma_addr_t dma)
+{
+ struct device *dev = rtwdev->dev;
+ int buf_sz = RTK_PCI_RX_BUF_SIZE;
+
+ dma_sync_single_for_cpu(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
+
+ return 0;
+}
+
+static int rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma,
+ struct rtw_pci_rx_ring *rx_ring,
+ u32 idx, u32 desc_sz)
+{
+ struct device *dev = rtwdev->dev;
+ struct rtw_pci_rx_buffer_desc *buf_desc;
+ int buf_sz = RTK_PCI_RX_BUF_SIZE;
+
+ dma_sync_single_for_device(dev, dma, buf_sz, PCI_DMA_FROMDEVICE);
+
+ buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head +
+idx * desc_sz);
+ memset(buf_desc, 0, sizeof(*buf_desc));
+ buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE);
+ buf_desc->dma = cpu_to_le32(dma);
+
+ return 0;
+}
+
static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev,
struct rtw_pci_rx_ring *rx_ring,
u8 desc_size, u32 len)
@@ -782,8 +811,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
rtw_pci_dma_check(rtwdev, ring, cur_rp);
skb = ring->buf[cur_rp];
dma = *((dma_addr_t *)skb->cb);
- pci_unmap_single(rtwpci->pdev, dma, RTK_PCI_RX_BUF_SIZE,
-PCI_DMA_FROMDEVICE);
+ rtw_pci_sync_rx_desc_cpu(rtwdev, dma);
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
_status);
@@ -818,7 +846,8 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
next_rp:
/* new skb delivered to mac80211, re-enable original skb DMA */
- rtw_pci_reset_rx_desc(rtwdev, skb, ring, cur_rp, buf_desc_sz);
+ rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp,
+ buf_desc_sz);
/* host read next element in ring */
if (++cur_rp >= ring->r.len)
--
2.22.0
[PATCH v2 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
[ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci :02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:091b6e66 len:415 put:415
head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
[ cut here ]
kernel BUG at net/core/skbuff.c:105!
invalid opcode: [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new, data-sized skb first in RX ISR. After
copying the data in, we pass it to the upper layers. However, if skb
allocation fails, we effectively drop the frame. In both cases, the
original, full size ring skb is reused.
In addition, to fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 49 +++-
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..e9fe3ad896c8 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -763,6 +763,7 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
u32 pkt_offset;
u32 pkt_desc_sz = chip->rx_pkt_desc_sz;
u32 buf_desc_sz = chip->rx_buf_desc_sz;
+ u32 new_len;
u8 *rx_desc;
dma_addr_t dma;
@@ -790,40 +791,34 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
pkt_stat.shift;
- if (pkt_stat.is_c2h) {
- /* keep rx_desc, halmac needs it */
- skb_put(skb, pkt_stat.pkt_len + pkt_offset);
+ /* discard current skb if the new skb cannot be allocated as a
+* new one in rx ring later
+*/
+ new_len = pkt_stat.pkt_len + pkt_offset;
+ new = dev_alloc_skb(new_len);
+ if (WARN_ONCE(!new, "rx routine starvation\n"))
+ goto next_rp;
+
+ /* put the DMA data including rx_desc from phy to new skb */
+ skb_put_data(new, skb->data, new_len);
- /* pass offset for further operation */
- *((u32 *)skb->cb) = pkt_offset;
- skb_queue_tail(>c2h_queue, skb);
+ if (pkt_stat.is_c2h) {
+/* pass rx_desc & offset for further operation */
+ *((u32 *)new->cb) = pkt_offset;
+ skb_queue_tail(>c2h_queue, new);
ieee80211_queue_work(rtwdev->hw, >c2h_work);
} else {
- /* remove rx_desc, maybe use skb_pull? */
- skb_put(skb, pkt_stat.pkt_len);
- skb_reserve(skb, pkt_offset);
-
- /* alloc a smaller skb to mac80211 */
- new = dev_alloc_skb(pkt_stat.pkt_len);
- if (!new) {
- new = skb;
- } else {
- skb_put_data(new, skb->data, skb->len);
- dev_kfree_skb_any(skb);
- }
- /* TODO: merge into rx.c */
- rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
+ /* remove rx_desc */
+ skb_pull(new, pkt_offset);
+
+ rtw_rx_stats(rtwdev, pkt_stat.vif, new);
memcpy(new->cb, _status, sizeof(rx_status));
ieee80211_rx_irqsafe(rtwdev->hw, new);
}
- /* skb delivered to mac80211, alloc a new one in rx ring */
- new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
- if (WARN(!new, "rx routine starvation\n"))
- return;
-
- ring->buf[cur_rp] = new;
- rtw_pci_reset_rx_desc(rtwdev, new
Re: [PATCH] rtw88/pci: Rearrange the memory usage for skb in RX ISR
Tony Chuang 於 2019年7月8日 週一 下午3:23寫道：
>
> > Subject: [PATCH] rtw88/pci: Rearrange the memory usage for skb in RX ISR
>
> nit, "rtw88: pci:" would be better.
Ok.
> >
> > When skb allocation fails and the "rx routine starvation" is hit, the
> > function returns immediately without updating the RX ring. At this
> > point, the RX ring may continue referencing an old skb which was already
> > handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> > bad things happen.
> >
> > This patch allocates a new skb first in RX ISR. If we don't have memory
> > available, we discard the current frame, allowing the existing skb to be
> > reused in the ring. Otherwise, we simplify the code flow and just hand
> > over the RX-populated skb over to mac80211.
> >
> > In addition, to fixing the kernel crash, the RX routine should now
> > generally behave better under low memory conditions.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> > Signed-off-by: Jian-Hong Pan
> > Reviewed-by: Daniel Drake
> > Cc:
> > ---
> > drivers/net/wireless/realtek/rtw88/pci.c | 28 +++-
> > 1 file changed, 13 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index cfe05ba7280d..1bfc99ae6b84 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -786,6 +786,15 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > rx_desc = skb->data;
> > chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
> > _status);
> >
> > + /* discard current skb if the new skb cannot be allocated as a
> > + * new one in rx ring later
> > + * */
>
> nit, comment indentation.
Thanks. I will fix this.
> > + new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
> > + if (WARN(!new, "rx routine starvation\n")) {
> > + new = skb;
> > + goto next_rp;
> > + }
> > +
> > /* offset from rx_desc to payload */
> > pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
> >pkt_stat.shift;
> > @@ -803,25 +812,14 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev,
> > struct rtw_pci *rtwpci,
> > skb_put(skb, pkt_stat.pkt_len);
> > skb_reserve(skb, pkt_offset);
> >
> > - /* alloc a smaller skb to mac80211 */
> > - new = dev_alloc_skb(pkt_stat.pkt_len);
> > - if (!new) {
> > - new = skb;
> > - } else {
> > - skb_put_data(new, skb->data, skb->len);
> > - dev_kfree_skb_any(skb);
> > - }
>
> I am not sure if it's fine to deliver every huge SKB to mac80211.
> Because it will then be delivered to TCP/IP stack.
> Hence I think either it should be tested to know if the performance
> would be impacted or find out a more efficient way to send
> smaller SKB to mac80211 stack.
I remember network stack only processes the skb with(in) pointers
(skb->data) and the skb->len for data part. It also checks real
buffer boundary (head and end) of the skb to prevent memory overflow.
Therefore, I think using the original skb is the most efficient way.
If I misunderstand something, please point out.
> > /* TODO: merge into rx.c */
> > rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
> > - memcpy(new->cb, _status, sizeof(rx_status));
> > - ieee80211_rx_irqsafe(rtwdev->hw, new);
> > + memcpy(skb->cb, _status, sizeof(rx_status));
> > + ieee80211_rx_irqsafe(rtwdev->hw, skb);
> > }
> >
> > - /* skb delivered to mac80211, alloc a new one in rx ring */
> > - new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
> > - if (WARN(!new, "rx routine starvation\n"))
> > - return;
> > -
> > +next_rp:
> > + /* skb delivered to mac80211, attach the new one into rx ring
> > */
> > ring->buf[cur_rp] = new;
> > rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_rp, buf_desc_sz);
> >
>
> --
>
> Yan-Hsuan
[PATCH] rtw88/pci: Rearrange the memory usage for skb in RX ISR
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
[ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci :02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:091b6e66 len:415 put:415
head:d2880c6f data:7a02b1ea tail:0x1df end:0xc0 dev:
[ cut here ]
kernel BUG at net/core/skbuff.c:105!
invalid opcode: [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new skb first in RX ISR. If we don't have memory
available, we discard the current frame, allowing the existing skb to be
reused in the ring. Otherwise, we simplify the code flow and just hand
over the RX-populated skb over to mac80211.
In addition, to fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
Signed-off-by: Jian-Hong Pan
Reviewed-by: Daniel Drake
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 28 +++-
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..1bfc99ae6b84 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -786,6 +786,15 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
_status);
+ /* discard current skb if the new skb cannot be allocated as a
+* new one in rx ring later
+* */
+ new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
+ if (WARN(!new, "rx routine starvation\n")) {
+ new = skb;
+ goto next_rp;
+ }
+
/* offset from rx_desc to payload */
pkt_offset = pkt_desc_sz + pkt_stat.drv_info_sz +
pkt_stat.shift;
@@ -803,25 +812,14 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
skb_put(skb, pkt_stat.pkt_len);
skb_reserve(skb, pkt_offset);
- /* alloc a smaller skb to mac80211 */
- new = dev_alloc_skb(pkt_stat.pkt_len);
- if (!new) {
- new = skb;
- } else {
- skb_put_data(new, skb->data, skb->len);
- dev_kfree_skb_any(skb);
- }
/* TODO: merge into rx.c */
rtw_rx_stats(rtwdev, pkt_stat.vif, skb);
- memcpy(new->cb, _status, sizeof(rx_status));
- ieee80211_rx_irqsafe(rtwdev->hw, new);
+ memcpy(skb->cb, _status, sizeof(rx_status));
+ ieee80211_rx_irqsafe(rtwdev->hw, skb);
}
- /* skb delivered to mac80211, alloc a new one in rx ring */
- new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
- if (WARN(!new, "rx routine starvation\n"))
- return;
-
+next_rp:
+ /* skb delivered to mac80211, attach the new one into rx ring */
ring->buf[cur_rp] = new;
rtw_pci_reset_rx_desc(rtwdev, new, ring, cur_rp, buf_desc_sz);
--
2.22.0
[PATCH v3] Bluetooth: btrtl: HCI reset on close for Realtek BT chip
Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
after on-off several times. Bluetooth daemon sets BT mode failed when
this issue happens. Scanning must be active while turning off for this
bug to be hit.
bluetoothd[1576]: Failed to set mode: Failed (0x03)
If BT is turned off, then turned on again, it works correctly again.
According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set
during probing. So, this patch makes Realtek's BT reset on close to fix
this issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
Signed-off-by: Jian-Hong Pan
---
v2:
- According to the vendor driver, it makes "all" Realtek's BT reset on
close. So, this version makes it the same.
- Change to the new subject for all Realtek BT chips.
v3:
- Fix the commit message and add the bug link.
- Have btrtl_shutdown_realtek() which sends HCI reset command and as
the callback function of hdev->shutdown for Realtek BT instead of
setting HCI_QUIRK_RESET_ON_CLOSE flag.
drivers/bluetooth/btrtl.c | 20
drivers/bluetooth/btrtl.h | 6 ++
drivers/bluetooth/btusb.c | 1 +
3 files changed, 27 insertions(+)
diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 208feef63de4..d04b443cad1f 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -637,6 +637,26 @@ int btrtl_setup_realtek(struct hci_dev *hdev)
}
EXPORT_SYMBOL_GPL(btrtl_setup_realtek);
+int btrtl_shutdown_realtek(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ int ret;
+
+ /* According to the vendor driver, BT must be reset on close to avoid
+* firmware crash.
+*/
+ skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ ret = PTR_ERR(skb);
+ bt_dev_err(hdev, "HCI reset during shutdown failed");
+ return ret;
+ }
+ kfree_skb(skb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(btrtl_shutdown_realtek);
+
static unsigned int btrtl_convert_baudrate(u32 device_baudrate)
{
switch (device_baudrate) {
diff --git a/drivers/bluetooth/btrtl.h b/drivers/bluetooth/btrtl.h
index f1676144fce8..10ad40c3e42c 100644
--- a/drivers/bluetooth/btrtl.h
+++ b/drivers/bluetooth/btrtl.h
@@ -55,6 +55,7 @@ void btrtl_free(struct btrtl_device_info *btrtl_dev);
int btrtl_download_firmware(struct hci_dev *hdev,
struct btrtl_device_info *btrtl_dev);
int btrtl_setup_realtek(struct hci_dev *hdev);
+int btrtl_shutdown_realtek(struct hci_dev *hdev);
int btrtl_get_uart_settings(struct hci_dev *hdev,
struct btrtl_device_info *btrtl_dev,
unsigned int *controller_baudrate,
@@ -83,6 +84,11 @@ static inline int btrtl_setup_realtek(struct hci_dev *hdev)
return -EOPNOTSUPP;
}
+static inline int btrtl_shutdown_realtek(struct hci_dev *hdev)
+{
+ return -EOPNOTSUPP;
+}
+
static inline int btrtl_get_uart_settings(struct hci_dev *hdev,
struct btrtl_device_info *btrtl_dev,
unsigned int *controller_baudrate,
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50aed5259c2b..342e1de6bcba 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3184,6 +3184,7 @@ static int btusb_probe(struct usb_interface *intf,
#ifdef CONFIG_BT_HCIBTUSB_RTL
if (id->driver_info & BTUSB_REALTEK) {
hdev->setup = btrtl_setup_realtek;
+ hdev->shutdown = btrtl_shutdown_realtek;
/* Realtek devices lose their updated firmware over suspend,
* but the USB hub doesn't notice any status change.
--
2.22.0
[PATCH v2] Bluetooth: btrtl: HCI reset on close for Realtek BT chip
Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly after on-off several times. Bluetooth daemon sets BT mode failed when this issue happens. bluetoothd[1576]: Failed to set mode: Failed (0x03) If BT is tunred off, then turned on again, it works correctly again. According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set during probing. So, this patch makes Realtek's BT reset on close to fix this issue. Signed-off-by: Jian-Hong Pan --- v2: - According to the vendor driver, it makes "all" Realtek's BT reset on close. So, this version makes it the same. - Change to the new subject for all Realtek BT chips. drivers/bluetooth/btrtl.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c index 208feef63de4..be6d5f7e1e44 100644 --- a/drivers/bluetooth/btrtl.c +++ b/drivers/bluetooth/btrtl.c @@ -630,6 +630,10 @@ int btrtl_setup_realtek(struct hci_dev *hdev) return PTR_ERR(btrtl_dev); ret = btrtl_download_firmware(hdev, btrtl_dev); + /* According to the vendor driver, BT must be reset on close to avoid +* firmware crash since kernel v3.7.1. +*/ + set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks); btrtl_free(btrtl_dev); -- 2.22.0
[PATCH] Bluetooth: btrtl: HCI reset on close for RTL8822BE
Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly after on-off several times. Bluetooth daemon sets BT mode failed when this issue happens. bluetoothd[1576]: Failed to set mode: Failed (0x03) If BT is tunred off, then turned on again, it works correctly again. This patch makes RTL8822BE BT reset on close to fix this issue. Signed-off-by: Jian-Hong Pan --- drivers/bluetooth/btrtl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c index 208feef63de4..7e9930f0f231 100644 --- a/drivers/bluetooth/btrtl.c +++ b/drivers/bluetooth/btrtl.c @@ -608,10 +608,11 @@ int btrtl_download_firmware(struct hci_dev *hdev, case RTL_ROM_LMP_8723A: case RTL_ROM_LMP_3499: return btrtl_setup_rtl8723a(hdev, btrtl_dev); + case RTL_ROM_LMP_8822B: + set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks); case RTL_ROM_LMP_8723B: case RTL_ROM_LMP_8821A: case RTL_ROM_LMP_8761A: - case RTL_ROM_LMP_8822B: return btrtl_setup_rtl8723b(hdev, btrtl_dev); default: rtl_dev_info(hdev, "rtl: assuming no firmware upload needed\n"); -- 2.20.1
[tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T
Commit-ID: 0082517fa4bce073e7cf542633439f26538a14cc
Gitweb: https://git.kernel.org/tip/0082517fa4bce073e7cf542633439f26538a14cc
Author: Jian-Hong Pan
AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
Committer: Ingo Molnar
CommitDate: Tue, 16 Apr 2019 10:01:24 +0200
x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T
Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.
The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.
Besides, the EFI mode cannot be disabled in the BIOS of this model.
However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.
So add a boot time quirk to use EFI reboot on such systems.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/reboot.c | 21 +
include/linux/efi.h | 7 ++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..8fd3cedd9acc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id
*d)
return 0;
}
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+ if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+ reboot_type = BOOT_EFI;
+ pr_info("%s series board detected. Selecting EFI-method for
reboot.\n", d->ident);
+ }
+ return 0;
+}
+
void __noreturn machine_real_restart(unsigned int type)
{
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+ { /* Handle reboot issue on Acer TravelMate X514-51T */
+ .callback = set_efi_reboot,
+ .ident = "Acer TravelMate X514-51T",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+ },
+ },
/* Apple */
{ /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 54357a258b35..6ebc2098cfe1 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1611,7 +1611,12 @@ efi_status_t efi_setup_gop(efi_system_table_t
*sys_table_arg,
struct screen_info *si, efi_guid_t *proto,
unsigned long size);
-bool efi_runtime_disabled(void);
+#ifdef CONFIG_EFI
+extern bool efi_runtime_disabled(void);
+#else
+static inline bool efi_runtime_disabled(void) { return true; }
+#endif
+
extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
extern unsigned long efi_call_virt_save_flags(void);
[tip:x86/urgent] x86/reboot: Use EFI reboot for Acer TravelMate X514-51T
Commit-ID: 5767575c1211e8958e5dd80d6542998b519c8478
Gitweb: https://git.kernel.org/tip/5767575c1211e8958e5dd80d6542998b519c8478
Author: Jian-Hong Pan
AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
Committer: Ingo Molnar
CommitDate: Tue, 16 Apr 2019 09:49:16 +0200
x86/reboot: Use EFI reboot for Acer TravelMate X514-51T
Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.
The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.
Besides, the EFI mode cannot be disabled in the BIOS of this model.
However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.
So add a boot time quirk to use EFI reboot on such systems.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Cc: li...@endlessm.com
Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-h...@endlessm.com
[ Small clarification edits to the code and changelog. ]
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/reboot.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..8fd3cedd9acc 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id
*d)
return 0;
}
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+ if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+ reboot_type = BOOT_EFI;
+ pr_info("%s series board detected. Selecting EFI-method for
reboot.\n", d->ident);
+ }
+ return 0;
+}
+
void __noreturn machine_real_restart(unsigned int type)
{
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+ { /* Handle reboot issue on Acer TravelMate X514-51T */
+ .callback = set_efi_reboot,
+ .ident = "Acer TravelMate X514-51T",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+ },
+ },
/* Apple */
{ /* Handle problems with rebooting on Apple MacBook5 */
[PATCH v2] x86/reboot: Use efi reboot for Acer TravelMate X514-51T
Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.
The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.
Besides, the EFI mode cannot be disabled in the BIOS of this model.
However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
v2:
- Add the EFI runtime state checking in set_efi_reboot function for the
quirk.
- Refine the printing information by writing "EFI" in the string
directly.
arch/x86/kernel/reboot.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..07111b8c41dd 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id
*d)
return 0;
}
+/*
+ * Some machines require the "reboot=e" commandline options
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+ if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+ reboot_type = BOOT_EFI;
+ pr_info("%s series board detected. Selecting EFI-method for
reboots.\n",
+ d->ident);
+ }
+ return 0;
+}
+
void __noreturn machine_real_restart(unsigned int type)
{
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+ { /* Handle reboot issue on Acer TravelMate X514-51T */
+ .callback = set_efi_reboot,
+ .ident = "Acer TravelMate X514-51T",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+ },
+ },
/* Apple */
{ /* Handle problems with rebooting on Apple MacBook5 */
--
2.20.1
Re: [PATCH] x86/reboot: Use efi reboot for Acer TravelMate X514-51T
Thomas Gleixner 於 2019年4月6日 週六 上午5:14寫道：
>
> On Mon, 1 Apr 2019, Jian-Hong Pan wrote:
> > +/*
> > + * Some machines require the "reboot=e" commandline options
> > + */
> > +static int __init set_efi_reboot(const struct dmi_system_id *d)
> > +{
> > + if (reboot_type != BOOT_EFI) {
> > + reboot_type = BOOT_EFI;
>
> So if EFI is disabled in the kernel this will fall through to BOOT_BIOS. Is
> that intended behaviour?
If not choose EFI as the reboot type, system will use APCI reboot type
on Acer TravelMate X514-51T.
If the reboot type is set as BIOS by appending "reboot=b", system
cannot reboot and hangs up when shutdown.
> > + pr_info("%s series board detected. Selecting %s-method for
> > reboot.\n",
> > + d->ident, "EFI");
>
> Is thee a reason not to write "EFI" in the string itself?
Just simply follow the format like functions: set_acpi_reboot, set_bios_reboot
https://elixir.bootlin.com/linux/v5.1-rc4/source/arch/x86/kernel/reboot.c#L60
BR,
Jian-Hong Pan
[PATCH] x86/reboot: Use efi reboot for Acer TravelMate X514-51T
Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
shutdown process, but then it hangs in BIOS POST with a black screen.
The problem is intermittent - at some points it has appeared related to
Secure Boot settings or different kernel builds, but ultimately we have
not been able to identify the exact conditions that trigger the issue to
come and go.
However, after extensive testing, we observe that using the EFI reboot
method reliably avoids the issue in all cases.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
arch/x86/kernel/reboot.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..145bdfb56a9a 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id
*d)
return 0;
}
+/*
+ * Some machines require the "reboot=e" commandline options
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+ if (reboot_type != BOOT_EFI) {
+ reboot_type = BOOT_EFI;
+ pr_info("%s series board detected. Selecting %s-method for
reboot.\n",
+ d->ident, "EFI");
+ }
+ return 0;
+}
+
void __noreturn machine_real_restart(unsigned int type)
{
local_irq_disable();
@@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+ { /* Handle reboot issue on Acer TravelMate X514-51T */
+ .callback = set_efi_reboot,
+ .ident = "Acer TravelMate X514-51T",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+ },
+ },
/* Apple */
{ /* Handle problems with rebooting on Apple MacBook5 */
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate B114-21 with ALC233
The Acer TravelMate B114-21 laptop cannot detect and record sound from
headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA verb
quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to fix
this issue.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a3fb3d4c5730..bdb2227be4eb 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5690,6 +5690,7 @@ enum {
ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC299_FIXUP_PREDATOR_SPK,
+ ALC233_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6713,6 +6714,15 @@ static const struct hda_fixup alc269_fixups[] = {
{ 0x21, 0x90170150 }, /* use as headset mic, without
its own jack detect */
{ }
}
+ [ALC233_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC233_FIXUP_ASUS_MIC_NO_PRESENCE
},
};
@@ -6737,6 +6747,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
[PATCH 3/3] ALSA: hda/realtek: Enable headset MIC of ASUS X430UN and X512DK with ALC256
The ASUS X430UN and X512DK with ALC256 cannot detect the headset MIC
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b8efb20916ba..af0b1bd650f8 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7347,6 +7347,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60130},
{0x14, 0x90170110},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60130},
+ {0x14, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
{0x1a, 0x90a70130},
{0x1b, 0x90170110},
--
2.20.1
[PATCH 2/3] ALSA: hda/realtek: Enable headset mic of ASUS P5440FF with ALC256
From: Chris Chiu
The ASUS laptop P5440FF with ALC256 can't detect the headset microphone
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 2523e495924e..b8efb20916ba 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7343,6 +7343,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x12, 0x90a60130},
+ {0x14, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
{0x1a, 0x90a70130},
{0x1b, 0x90170110},
--
2.20.1
[PATCH 1/3] ALSA: hda/realtek: Enable ASUS X441MB and X705FD headset MIC with ALC256
The ASUS laptop X441MB and X705FD with ALC256 cannot detect the headset
MIC until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 89a96442eb07..2523e495924e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5688,6 +5688,7 @@ enum {
ALC225_FIXUP_WYSE_AUTO_MUTE,
ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
+ ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6696,6 +6697,15 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
},
+ [ALC256_FIXUP_ASUS_MIC_NO_PRESENCE] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x04a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7333,6 +7343,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
+ {0x1a, 0x90a70130},
+ {0x1b, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell",
ALC274_FIXUP_DELL_AIO_LINEOUT_VERB,
{0x12, 0xb7a60130},
{0x13, 0xb8a61140},
--
2.20.1
[PATCH] ALSA: hda/realtek - Add support for Acer Aspire E5-523G/ES1-432 headset mic
From: Chris Chiu
The Acer laptop Aspire E5-523G and ES1-432 with ALC255 can't detect
the headset microphone until ALC255_FIXUP_ACER_MIC_NO_PRESENCE quirk
applied.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 191830d4fa40..89a96442eb07 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6712,6 +6712,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
+ SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer Aspire Z24-890 with ALC286
The Acer Aspire Z24-890 cannot detect the headset MIC until
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk applied.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 191830d4fa40..916bb5a3f324 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6715,6 +6715,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
Re: [PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Takashi Iwai 於 2019年3月15日 週五 下午7:24寫道：
>
> On Fri, 15 Mar 2019 10:51:09 +0100,
> Jian-Hong Pan wrote:
> >
> > Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
> > record sound from headset MIC. This patch adds the
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2: According to Realtek's suggestion, change the COEF 0x4f from 0xd429 to
> > 0x5029. Thanks to Realtek!
>
> It'd be nicer if we get either Acked-by or Reviewed-by tag from
> Realtek. Kailang?
Hi Kailang,
May we have your Acked-by or Reviewed-by tag for this patch?
Signed-off will also be great!
Thank you
Jian-Hong Pan
> thanks,
>
> Takashi
>
> >
> > sound/pci/hda/patch_realtek.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 384719d5c44e..191830d4fa40 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5687,6 +5687,7 @@ enum {
> > ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE,
> > ALC225_FIXUP_WYSE_AUTO_MUTE,
> > ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
> > + ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> > };
> >
> > static const struct hda_fixup alc269_fixups[] = {
> > @@ -6685,6 +6686,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > },
> > + [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_VERBS,
> > + .v.verbs = (const struct hda_verb[]) {
> > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
> > + { 0x20, AC_VERB_SET_PROC_COEF, 0x5029 },
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
> > + },
> > };
> >
> > static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -6701,9 +6712,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[]
> > = {
> > SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
> > ALC282_FIXUP_ASPIRE_V5_PINS),
> > SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
> > ALC283_FIXUP_CHROME_BOOK),
> > - SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > - SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
> > + SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > + SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
> > SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
> > ALC275_FIXUP_DELL_XPS),
> > --
> > 2.20.1
> >
> >
[PATCH v2] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
Signed-off-by: Jian-Hong Pan
---
v2: According to Realtek's suggestion, change the COEF 0x4f from 0xd429 to
0x5029. Thanks to Realtek!
sound/pci/hda/patch_realtek.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 384719d5c44e..191830d4fa40 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5687,6 +5687,7 @@ enum {
ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE,
ALC225_FIXUP_WYSE_AUTO_MUTE,
ALC225_FIXUP_WYSE_DISABLE_MIC_VREF,
+ ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6685,6 +6686,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x5029 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6701,9 +6712,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
- SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a63670013943..b3fbad5a680f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5695,6 +5695,7 @@ enum {
ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
ALC255_FIXUP_ACER_HEADSET_MIC,
ALC295_FIXUP_CHROME_BOOK,
+ ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6677,6 +6678,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC225_FIXUP_HEADSET_JACK
},
+ [ALC286_FIXUP_ACER_AIO_HEADSET_MIC] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x4f },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0xd429 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6693,9 +6704,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G",
ALC282_FIXUP_ASPIRE_V5_PINS),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
- SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable headset MIC of Acer TravelMate X514-51T with ALC255
The Acer TravelMate X514-51T with ALC255 cannot detect the headset MIC
until ALC255_FIXUP_ACER_HEADSET_MIC quirk applied. Although, the
internal DMIC uses another module - snd_soc_skl as the driver. We still
need the NID 0x1a in the quirk to enable the headset MIC.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Kailang Yang
---
sound/pci/hda/patch_realtek.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index c8413d44973c..8debd661e6f2 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5673,6 +5673,7 @@ enum {
ALC225_FIXUP_HEADSET_JACK,
ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE,
ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
+ ALC255_FIXUP_ACER_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6639,6 +6640,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC285_FIXUP_LENOVO_HEADPHONE_NOISE
},
+ [ALC255_FIXUP_ACER_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x03a11130 },
+ { 0x1a, 0x90a60140 }, /* use as internal mic */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC255_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6658,6 +6669,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
SND_PCI_QUIRK(0x1028, 0x054b, "Dell XPS one 2710",
ALC275_FIXUP_DELL_XPS),
SND_PCI_QUIRK(0x1028, 0x05bd, "Dell Latitude E6440",
ALC292_FIXUP_DELL_E7X),
--
2.20.1
[PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS UX362FA with ALC294
The ASUS UX362FA with ALC294 cannot detect the headset MIC and outputs
through the internal speaker and the headphone. This issue can be fixed
by the quirk in the commit 4e0511067 ALSA: hda/realtek: Enable audio
jacks of ASUS UX533FD with ALC294.
Besides, ASUS UX362FA and UX533FD have the same audio initial pin config
values. So, this patch replaces SND_PCI_QUIRK of UX533FD with a new
SND_HDA_PIN_QUIRK which benefits both UX362FA and UX533FD.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Ming Shuo Chiu
---
sound/pci/hda/patch_realtek.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1ffa36e987b4..6421864a8a0f 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6771,7 +6771,6 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
- SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", ALC294_FIXUP_ASUS_SPK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
@@ -7388,6 +7387,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x03211020}),
SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
{0x12, 0x90a60130},
{0x17, 0x90170110},
--
2.20.1
Re: [RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Andreas Färber 於 2019年1月16日 週三 下午10:50寫道： > > Am 16.01.19 um 15:36 schrieb Jiri Pirko: > > Wed, Jan 16, 2019 at 03:25:02PM CET, starni...@g.ncu.edu.tw wrote: > >> Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into > >> another header lora/lorawan_skb.h. > > > > What is the motivation for this change? > > I suggested it because skbs could be used with either LoRa or LoRaWAN > netdevs. I have a lora/skb.h. > > In general the lorawan_foo.h looks ugly to me, so I thought I suggested > to avoid that by using [lora/]lorawan/skb.h? Seems we have some choices: 1. Split the lorawan skb stuff from lora/lorawan_netdev.h and merge into include/linux/lora/skb.h 2. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lora/lorawan_skb.h 3. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lora/lorawan/skb.h 4. Split the lorawan skb stuff from lora/lorawan_netdev.h to include/linux/lorawan/skb.h #1, #2 and #3 are good to me. So, the intersection is choice #3. Regards, Jian-Hong Pan
Re: [RFC PATCH 1/5] net: lorawan: Refine the coding style
Andreas Färber 於 2019年1月16日 週三 下午11:07寫道： > > Am 16.01.19 um 15:33 schrieb Jiri Pirko: > > Wed, Jan 16, 2019 at 03:24:54PM CET, starni...@g.ncu.edu.tw wrote: > >> Signed-off-by: Jian-Hong Pan > >> --- > > > > Patches like this are in general frowned upon. Do one change in one > > patch. Put some patch description. > > This patch simply shouldn't have gone to netdev and LKML, as it is a > fixup against a non-stable tree (missing "lora-next"). Once squashed, it > doesn't matter whether it once had a verbose explanation or not. And I > prefer to not mix style and functional changes. Uh! I see. Regards, Jian-Hong Pan > I simply was too impatient to wait for more respins before being able to > base work on it. ;)
[RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into
another header lora/lorawan_skb.h.
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 20 -
include/linux/lora/lorawan_skb.h| 33 +
net/lorawan/socket.c| 1 +
3 files changed, 34 insertions(+), 20 deletions(-)
create mode 100644 include/linux/lora/lorawan_skb.h
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index a6c94cb96bf4..e515ba1ab508 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -28,24 +28,4 @@ struct sockaddr_lorawan {
struct lrw_addr_in addr_in;
};
-/**
- * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
- *
- * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
- */
-struct lrw_mac_cb {
- u32 devaddr;
-};
-
-/**
- * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
- * @skb: the exchanging sk_buff
- *
- * Return: the pointer of LoRaWAN MAC control buffer
- */
-static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
-{
- return (struct lrw_mac_cb *)skb->cb;
-}
-
#endif
diff --git a/include/linux/lora/lorawan_skb.h b/include/linux/lora/lorawan_skb.h
new file mode 100644
index ..ea4f900b37be
--- /dev/null
+++ b/include/linux/lora/lorawan_skb.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * LoRaWAN socket buffer related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong Pan
+ */
+
+#ifndef __LORAWAN_SKB_H__
+#define __LORAWAN_SKB_H__
+
+#include
+
+/**
+ * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
+ *
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ */
+struct lrw_mac_cb {
+ u32 devaddr;
+};
+
+/**
+ * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
+ * @skb: the exchanging sk_buff
+ *
+ * Return: the pointer of LoRaWAN MAC control buffer
+ */
+static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
+{
+ return (struct lrw_mac_cb *)skb->cb;
+}
+
+#endif
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7139fab63159..50559ba0c538 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include /* For TIOCOUTQ/INQ */
--
2.20.1
[RFC PATCH 4/5] net: lorawan: Fulfill the help text of Kconfig
Mention the LoRaWAN network feature to distinguish it from other Low-Power Wide-Area Network like Sigfox and NB-IoT. Signed-off-by: Jian-Hong Pan --- net/lorawan/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig index bf6c9b77573b..ce3ed6e6d11c 100644 --- a/net/lorawan/Kconfig +++ b/net/lorawan/Kconfig @@ -4,7 +4,8 @@ config LORAWAN LoRaWAN defines low data rate, low power and long range wireless wide area networks. It was designed to organize networks of automation devices, such as sensors, switches and actuators. It can operate - multiple kilometers wide. + multiple kilometers wide. The network is client/server technology + centered around gateways. Say Y here to compile LoRaWAN support into the kernel or say M to compile it as a module. -- 2.20.1
[RFC PATCH 5/5] net: lorawan: Split skb definitions into another header
Split LoRaWAN related skb definitions from lora/lorawan_netdev.h into
another header lora/lorawan_skb.h.
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 20 -
include/linux/lora/lorawan_skb.h| 33 +
net/lorawan/socket.c| 1 +
3 files changed, 34 insertions(+), 20 deletions(-)
create mode 100644 include/linux/lora/lorawan_skb.h
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index a6c94cb96bf4..e515ba1ab508 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -28,24 +28,4 @@ struct sockaddr_lorawan {
struct lrw_addr_in addr_in;
};
-/**
- * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
- *
- * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
- */
-struct lrw_mac_cb {
- u32 devaddr;
-};
-
-/**
- * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
- * @skb: the exchanging sk_buff
- *
- * Return: the pointer of LoRaWAN MAC control buffer
- */
-static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
-{
- return (struct lrw_mac_cb *)skb->cb;
-}
-
#endif
diff --git a/include/linux/lora/lorawan_skb.h b/include/linux/lora/lorawan_skb.h
new file mode 100644
index ..ea4f900b37be
--- /dev/null
+++ b/include/linux/lora/lorawan_skb.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * LoRaWAN socket buffer related definitions
+ *
+ * Copyright (c) 2018 Jian-Hong Pan
+ */
+
+#ifndef __LORAWAN_SKB_H__
+#define __LORAWAN_SKB_H__
+
+#include
+
+/**
+ * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
+ *
+ * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
+ */
+struct lrw_mac_cb {
+ u32 devaddr;
+};
+
+/**
+ * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
+ * @skb: the exchanging sk_buff
+ *
+ * Return: the pointer of LoRaWAN MAC control buffer
+ */
+static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
+{
+ return (struct lrw_mac_cb *)skb->cb;
+}
+
+#endif
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7139fab63159..50559ba0c538 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include /* For TIOCOUTQ/INQ */
--
2.20.1
[RFC PATCH 3/5] net; lorawan: Fix net device leakage
The net device may be missed to be put after error check. This patch
fixes the issue to prevent the leakage.
Signed-off-by: Jian-Hong Pan
---
net/lorawan/socket.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 9c0722379e25..7139fab63159 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -51,8 +51,10 @@ lrw_get_dev_by_addr(struct net *net, u32 devaddr)
rcu_read_lock();
ndev = dev_getbyhwaddr_rcu(net, ARPHRD_LORAWAN, (char *)_addr);
- if (ndev)
+ if (ndev && ndev->type == ARPHRD_LORAWAN)
dev_hold(ndev);
+ else
+ ndev = NULL;
rcu_read_unlock();
return ndev;
@@ -99,11 +101,6 @@ dgram_bind(struct sock *sk, struct sockaddr *uaddr, int len)
}
netdev_dbg(ndev, "%s: get ndev\n", __func__);
- if (ndev->type != ARPHRD_LORAWAN) {
- ret = -ENODEV;
- goto dgram_bind_end;
- }
-
ro->src_devaddr = addr->addr_in.devaddr;
ro->bound = 1;
ret = 0;
@@ -152,7 +149,7 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
if (size > ndev->mtu) {
netdev_dbg(ndev, "size = %zu, mtu = %u\n", size, ndev->mtu);
ret = -EMSGSIZE;
- goto dgram_sendmsg_end;
+ goto dgram_sendmsg_no_skb;
}
netdev_dbg(ndev, "%s: create skb\n", __func__);
@@ -189,7 +186,6 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
kfree_skb(skb);
dgram_sendmsg_no_skb:
dev_put(ndev);
-
dgram_sendmsg_end:
return ret;
}
--
2.20.1
[RFC PATCH 2/5] net: lorawan: Remove unused lrw_dev_hard_header function
The lorawan module is an abastraction layer over the LoRaWAN soft and
hard MAC. It passes the original buffer to the real MAC layer. So,
this patch removes the lrw_dev_hard_header function.
Signed-off-by: Jian-Hong Pan
---
net/lorawan/socket.c | 12
1 file changed, 12 deletions(-)
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 0ec2d2bf1682..9c0722379e25 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -115,14 +115,6 @@ dgram_bind(struct sock *sk, struct sockaddr *uaddr, int
len)
return ret;
}
-static int
-lrw_dev_hard_header(struct sk_buff *skb, struct net_device *ndev,
- const u32 src_devaddr, size_t len)
-{
- /* TODO: Prepare the LoRaWAN sending header here */
- return 0;
-}
-
static int
dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
{
@@ -176,10 +168,6 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
- ret = lrw_dev_hard_header(skb, ndev, 0, size);
- if (ret < 0)
- goto dgram_sendmsg_no_skb;
-
ret = memcpy_from_msg(skb_put(skb, size), msg, size);
if (ret > 0)
goto dgram_sendmsg_err_skb;
--
2.20.1
[RFC PATCH 1/5] net: lorawan: Refine the coding style
Signed-off-by: Jian-Hong Pan
---
include/linux/lora/lorawan_netdev.h | 5 ++--
net/lorawan/socket.c| 43 ++---
2 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/include/linux/lora/lorawan_netdev.h
b/include/linux/lora/lorawan_netdev.h
index 5bffb5164f95..a6c94cb96bf4 100644
--- a/include/linux/lora/lorawan_netdev.h
+++ b/include/linux/lora/lorawan_netdev.h
@@ -1,9 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
-/*-
+/*
* LoRaWAN stack related definitions
*
- * Copyright (c) 2018 Jian-Hong, Pan
- *
+ * Copyright (c) 2018 Jian-Hong Pan
*/
#ifndef __LORAWAN_NET_DEVICE_H__
diff --git a/net/lorawan/socket.c b/net/lorawan/socket.c
index 7ef106b877ca..0ec2d2bf1682 100644
--- a/net/lorawan/socket.c
+++ b/net/lorawan/socket.c
@@ -1,36 +1,33 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
-/*-
+/*
* LoRaWAN stack related definitions
*
- * Copyright (c) 2018 Jian-Hong, Pan
- *
+ * Copyright (c) 2018 Jian-Hong Pan
*/
#defineLORAWAN_MODULE_NAME "lorawan"
#definepr_fmt(fmt) LORAWAN_MODULE_NAME ": " fmt
+#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include /* For TIOCOUTQ/INQ */
#include
-#include
/**
* dgram_sock - This structure holds the states of Datagram socket
*
* @sk:network layer representation of the socket
- * sk must be the first member of dgram_sock
* @src_devaddr: the LoRaWAN device address for this connection
* @bound: this socket is bound or not
* @connected: this socket is connected to the destination or not
- * @want_ack: this socket needs to ack for the connection or not
*/
struct dgram_sock {
- struct sock sk;
+ struct sock sk; /* sk must be the first member of dgram_sock */
u32 src_devaddr;
u8 bound:1;
@@ -136,7 +133,7 @@ dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t
size)
size_t tlen;
int ret;
- pr_debug("%s: going to send %zu bytes", __func__, size);
+ pr_debug("%s: going to send %zu bytes\n", __func__, size);
if (msg->msg_flags & MSG_OOB) {
pr_debug("msg->msg_flags = 0x%x\n", msg->msg_flags);
return -EOPNOTSUPP;
@@ -532,7 +529,7 @@ static const struct proto_ops lrw_dgram_ops = {
};
static int
-lorawan_creat(struct net *net, struct socket *sock, int protocol, int kern)
+lrw_create(struct net *net, struct socket *sock, int protocol, int kern)
{
struct sock *sk;
int ret;
@@ -557,7 +554,7 @@ lorawan_creat(struct net *net, struct socket *sock, int
protocol, int kern)
ret = sk->sk_prot->hash(sk);
if (ret) {
sk_common_release(sk);
- goto lorawan_creat_end;
+ goto lrw_create_end;
}
}
@@ -567,14 +564,14 @@ lorawan_creat(struct net *net, struct socket *sock, int
protocol, int kern)
sk_common_release(sk);
}
-lorawan_creat_end:
+lrw_create_end:
return ret;
}
static const struct net_proto_family lorawan_family_ops = {
.owner = THIS_MODULE,
.family = PF_LORAWAN,
- .create = lorawan_creat,
+ .create = lrw_create,
};
static int
@@ -617,29 +614,29 @@ lrw_dgram_deliver(struct net_device *ndev, struct sk_buff
*skb)
}
static int
-lorawan_rcv(struct sk_buff *skb, struct net_device *ndev,
+lrw_rcv(struct sk_buff *skb, struct net_device *ndev,
struct packet_type *pt, struct net_device *orig_ndev)
{
if (!netif_running(ndev))
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (!net_eq(dev_net(ndev), _net))
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (ndev->type != ARPHRD_LORAWAN)
- goto lorawan_rcv_drop;
+ goto lrw_rcv_drop;
if (skb->pkt_type != PACKET_OTHERHOST)
return lrw_dgram_deliver(ndev, skb);
-lorawan_rcv_drop:
+lrw_rcv_drop:
kfree_skb(skb);
return NET_RX_DROP;
}
static struct packet_type lorawan_packet_type = {
.type = htons(ETH_P_LORAWAN),
- .func = lorawan_rcv,
+ .func = lrw_rcv,
};
static int __init
@@ -665,7 +662,7 @@ lrw_sock_init(void)
proto_unregister(_dgram_prot);
lrw_sock_init_end:
- return 0;
+ return ret;
}
static void __exit
@@ -680,7 +677,7 @@ lrw_sock_exit(void)
module_init(lrw_sock_init);
module_exit(lrw_sock_exit);
-MODULE_AUTHOR("Jian-Hong Pan, ");
-MODULE_DESCRIPTION("LoRaWAN socket kernel module");
+MODULE_AUTHOR("Jian-Hong Pan ");
+MODULE_DESCRIPTION("LoRaWAN socket protocol");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS_NETPROTO(PF_LORAWAN);
--
2.20.1
[RFC PATCH 0/5] net: lorawan: Refine the lorawan protocol module
Jian-Hong Pan (5): net: lorawan: Refine the coding style net: lorawan: Remove unused lrw_dev_hard_header function net; lorawan: Fix net device leakage net: lorawan: Fulfill the help text of Kconfig net: lorawan: Split skb definitions into another header include/linux/lora/lorawan_netdev.h | 25 +-- include/linux/lora/lorawan_skb.h| 33 ++ net/lorawan/Kconfig | 3 +- net/lorawan/socket.c| 68 +++-- 4 files changed, 62 insertions(+), 67 deletions(-) create mode 100644 include/linux/lora/lorawan_skb.h -- 2.20.1
Re: [PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
Jian-Hong Pan 於 2019年1月7日 週一 下午10:47寫道：
>
> Andreas Färber 於 2018年12月29日 週六 下午3:27寫道：
> >
> > Hi Jian-Hong,
> >
> > Am 16.12.18 um 11:18 schrieb Jian-Hong Pan:
> > > This patch adds a new address/protocol family for LoRaWAN network.
> > > It also implements the the functions and maps to Datagram socket for
> > > LoRaWAN unconfirmed data messages.
> > >
> > > Signed-off-by: Jian-Hong Pan
> > [...]
> > > include/linux/lora/lorawan_netdev.h | 52 +++
> > > net/lorawan/Kconfig | 10 +
> > > net/lorawan/Makefile| 2 +
> > > net/lorawan/socket.c| 686
> > > 4 files changed, 750 insertions(+)
> > > create mode 100644 include/linux/lora/lorawan_netdev.h
> > > create mode 100644 net/lorawan/Kconfig
> > > create mode 100644 net/lorawan/Makefile
> > > create mode 100644 net/lorawan/socket.c
> >
> > I'm not 100% happy with this yet, but to decouple it from the soft-MAC
> > discussion (patches 2-6/6) and to allow reuse by Ben, I've staged it in
> > linux-lora.git.
> >
> > We can clean it up with incremental patches there (and squash later).
> >
> > >
> > > diff --git a/include/linux/lora/lorawan_netdev.h
> > > b/include/linux/lora/lorawan_netdev.h
> > > new file mode 100644
> > > index ..5bffb5164f95
> > > --- /dev/null
> > > +++ b/include/linux/lora/lorawan_netdev.h
> > > @@ -0,0 +1,52 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
> >
> > Is there any practical reason you dual-license your code? My LoRa code
> > is only GPL - should I reconsider that?
>
> I use dual-license due to the event "[Ksummit-discuss] [CORE TOPIC]
> GPL defense issues"
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html
>
> > > +/*-
> >
> > I assume the dash is a typo?
> >
> > > + * LoRaWAN stack related definitions
> > > + *
> > > + * Copyright (c) 2018 Jian-Hong, Pan
> > > + *
> >
> > Leftover white line from old license header?
> >
> > > + */
> > > +
> > > +#ifndef __LORAWAN_NET_DEVICE_H__
> > > +#define __LORAWAN_NET_DEVICE_H__
> > > +
> > > +enum {
> > > + LRW_ADDR_APPEUI,
> > > + LRW_ADDR_DEVEUI,
> > > + LRW_ADDR_DEVADDR,
> > > +};
> > > +
> > > +struct lrw_addr_in {
> > > + int addr_type;
> > > + union {
> > > + u64 app_eui;
> > > + u64 dev_eui;
> >
> > In my RFC and in linux-lora.git I have a lora_eui typedef - any reason
> > you're not using it here?
>
> lora_eui is defined as a type of u8 array with 8 bytes in
> include/linux/lora/dev.h
> typedef u8 lora_eui[8];
> It is not a basic nor simple data type.
>
> 1. There is the endian issue. LoRaWAN uses little endian for
> transmission. If u64 data type is used, we can call functions like
> cpu_to_le64 and le64_to_cpu to deal the endian jobs directly.
> 2. We can compare the EUIs with relational operators directly if the
> EUI is not a type of array.
>
> > > + u32 devaddr;
> > > + };
> > > +};
> > > +
> > > +struct sockaddr_lorawan {
> > > + sa_family_t family; /* AF_LORAWAN */
> > > + struct lrw_addr_in addr_in;
> > > +};
> > > +
> > > +/**
> > > + * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
> > > + *
> > > + * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
> > > + */
> > > +struct lrw_mac_cb {
> > > + u32 devaddr;
> > > +};
> > > +
> > > +/**
> > > + * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
> > > + * @skb: the exchanging sk_buff
> > > + *
> > > + * Return: the pointer of LoRaWAN MAC control buffer
> > > + */
> > > +static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
> > > +{
> > > + return (struct lrw_mac_cb *)skb->cb;
> > > +}
> >
> > For LoRa I have a separate lora/skb.h - suggest to split this off into
> > its own header consistently.
>
> Sounds good.
> Do you prefer separate them into lora/skb.h or lora/lorawan_skb.h?
>
> > > +
> > > +#endif
> > > diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
> > > new file mode 100644
> >
Re: [PATCH v5 1/6] net: lorawan: Add LoRaWAN socket module
Andreas Färber 於 2018年12月29日 週六 下午3:27寫道：
>
> Hi Jian-Hong,
>
> Am 16.12.18 um 11:18 schrieb Jian-Hong Pan:
> > This patch adds a new address/protocol family for LoRaWAN network.
> > It also implements the the functions and maps to Datagram socket for
> > LoRaWAN unconfirmed data messages.
> >
> > Signed-off-by: Jian-Hong Pan
> [...]
> > include/linux/lora/lorawan_netdev.h | 52 +++
> > net/lorawan/Kconfig | 10 +
> > net/lorawan/Makefile| 2 +
> > net/lorawan/socket.c| 686
> > 4 files changed, 750 insertions(+)
> > create mode 100644 include/linux/lora/lorawan_netdev.h
> > create mode 100644 net/lorawan/Kconfig
> > create mode 100644 net/lorawan/Makefile
> > create mode 100644 net/lorawan/socket.c
>
> I'm not 100% happy with this yet, but to decouple it from the soft-MAC
> discussion (patches 2-6/6) and to allow reuse by Ben, I've staged it in
> linux-lora.git.
>
> We can clean it up with incremental patches there (and squash later).
>
> >
> > diff --git a/include/linux/lora/lorawan_netdev.h
> > b/include/linux/lora/lorawan_netdev.h
> > new file mode 100644
> > index ..5bffb5164f95
> > --- /dev/null
> > +++ b/include/linux/lora/lorawan_netdev.h
> > @@ -0,0 +1,52 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
>
> Is there any practical reason you dual-license your code? My LoRa code
> is only GPL - should I reconsider that?
I use dual-license due to the event "[Ksummit-discuss] [CORE TOPIC]
GPL defense issues"
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html
> > +/*-
>
> I assume the dash is a typo?
>
> > + * LoRaWAN stack related definitions
> > + *
> > + * Copyright (c) 2018 Jian-Hong, Pan
> > + *
>
> Leftover white line from old license header?
>
> > + */
> > +
> > +#ifndef __LORAWAN_NET_DEVICE_H__
> > +#define __LORAWAN_NET_DEVICE_H__
> > +
> > +enum {
> > + LRW_ADDR_APPEUI,
> > + LRW_ADDR_DEVEUI,
> > + LRW_ADDR_DEVADDR,
> > +};
> > +
> > +struct lrw_addr_in {
> > + int addr_type;
> > + union {
> > + u64 app_eui;
> > + u64 dev_eui;
>
> In my RFC and in linux-lora.git I have a lora_eui typedef - any reason
> you're not using it here?
lora_eui is defined as a type of u8 array with 8 bytes in
include/linux/lora/dev.h
typedef u8 lora_eui[8];
It is not a basic nor simple data type.
1. There is the endian issue. LoRaWAN uses little endian for
transmission. If u64 data type is used, we can call functions like
cpu_to_le64 and le64_to_cpu to deal the endian jobs directly.
2. We can compare the EUIs with relational operators directly if the
EUI is not a type of array.
> > + u32 devaddr;
> > + };
> > +};
> > +
> > +struct sockaddr_lorawan {
> > + sa_family_t family; /* AF_LORAWAN */
> > + struct lrw_addr_in addr_in;
> > +};
> > +
> > +/**
> > + * lrw_mac_cb - This structure holds the control buffer (cb) of sk_buff
> > + *
> > + * @devaddr: the LoRaWAN device address of this LoRaWAN hardware
> > + */
> > +struct lrw_mac_cb {
> > + u32 devaddr;
> > +};
> > +
> > +/**
> > + * lrw_get_mac_cb - Get the LoRaWAN MAC control buffer of the sk_buff
> > + * @skb: the exchanging sk_buff
> > + *
> > + * Return: the pointer of LoRaWAN MAC control buffer
> > + */
> > +static inline struct lrw_mac_cb *lrw_get_mac_cb(struct sk_buff *skb)
> > +{
> > + return (struct lrw_mac_cb *)skb->cb;
> > +}
>
> For LoRa I have a separate lora/skb.h - suggest to split this off into
> its own header consistently.
Sounds good.
Do you prefer separate them into lora/skb.h or lora/lorawan_skb.h?
> > +
> > +#endif
> > diff --git a/net/lorawan/Kconfig b/net/lorawan/Kconfig
> > new file mode 100644
> > index ..bf6c9b77573b
> > --- /dev/null
> > +++ b/net/lorawan/Kconfig
> > @@ -0,0 +1,10 @@
> > +config LORAWAN
> > + tristate "LoRaWAN Network support"
>
> The N in LoRaWAN is already for Network. :)
>
> > + help
> > + LoRaWAN defines low data rate, low power and long range wireless
> > + wide area networks. It was designed to organize networks of
> > automation
> > + devices, such as sensors, switches and actuators. It can operate
> > + multiple kilometers wide.
>
> The missing information here to distinguish it from LoRa
[PATCH] ALSA: hda/realtek: Enable the headset mic auto detection for ASUS laptops
The headset mic of ASUS laptops like UX533FD, UX433FN and UX333FA, whose
CODEC is Realtek ALC294 has jack auto detection feature. This patch
enables the feature.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a4f4a9dd488d..aee4cbd29d53 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6501,7 +6501,7 @@ static const struct hda_fixup alc269_fixups[] = {
[ALC294_FIXUP_ASUS_HEADSET_MIC] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
- { 0x19, 0x01a1113c }, /* use as headset mic, without
its own jack detect */
+ { 0x19, 0x01a1103c }, /* use as headset mic */
{ }
},
.chained = true,
--
2.11.0
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> > Am 18.12.18 um 15:27 schrieb Jian-Hong Pan: > > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > > >>> LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa > > devices. > > >>> > > >>> This patch implements part of Class A end-devices SoftMAC defined in > > >>> LoRaWAN(TM) Specification Ver. 1.0.2: > > >>> 1. End-device receive slot timing > > >>> 2. Only single channel and single data rate for now > > >>> 3. Unconfirmed data up/down message types > > >>> > > >>> On the other side, it defines the basic interface and operation > > >>> functions for compatible LoRa device drivers. > > >>> > > >>> Signed-off-by: Jian-Hong Pan > > [...] > > >>> net/maclorawan/Kconfig | 14 + > > >>> net/maclorawan/Makefile | 2 + > > >>> net/maclorawan/mac.c| 555 > > > > >>> net/maclorawan/main.c | 606 > > > > >>> 4 files changed, 1177 insertions(+) > > >>> create mode 100644 net/maclorawan/Kconfig > > >>> create mode 100644 net/maclorawan/Makefile > > >>> create mode 100644 net/maclorawan/mac.c > > >>> create mode 100644 net/maclorawan/main.c > > >> > > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > > >> you add headers for "API" and here you implement functions. That is just > > >> weird. Does it mean you can have other implementations? > > > > > > LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > > > This part is soft-MAC as Andreas mentioned > > > http://lists.infradead.org/pipermail/linux-lpwan/2018- > > December/10.html > > > > > >> Also, you don't really have any user of this API in the set. Please > > >> introduce at least 1 driver, preferably more (I see that Andreas has > > >> multiple ones in his patchset). You cannot push kernel infrastructure > > >> without kernel user. > > > > > > The soft-MAC is suitable for the LoRa chips' device drivers, like > > > sx1276/77/78/79, RFM95/96/97/98W ... > > > Still waiting for Andreas' sx1276 version 2 patch and more discussion. > > > > sx1276 regmap conversion was pushed to my staging tree together with > > Ben's sx1301 final conversion last night, lightly tested. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux- > > lora.git/log/?h=lora-next > > > > TBD: rename to sx127x, implement regmap fields, only auto-detect reset > > when no OF node available (all low priority atm, patches welcome) > > > > (and for sx1301 I still need to update my DT overlays with the new clk) > > > > > For example, how to make PF_LORA and PF_LORAWAN like Ethernet, > > PF_INET > > > and PF_INET6 don't need separate devices either, both use eth0. > > > https://lkml.org/lkml/2018/8/3/266 > > > > Jiri, I am expecting the maclorawan driver to lower packets from > > ETH_P_LORAWAN to ETH_P_LORA in a generic way, so that any of the LoRa > > device drivers can benefit of it, with maclorawan using the LoRa netlink > > commands that the individual drivers implement. > > Not sure what if anything is missing for that in the current revision? > > Still dealing with the lower-level infrastructure and my test setup ... > > progressing slowly. > > > > I'll probably need to queue the remaining generic LoRaWAN part 1/6 in my > > tree to resolve this circular dependency between Jian-Hong and me, so > > that only the soft-MAC implementation remains a separate patch series. > > The hard-MAC implementations will be on my plate mostly, as both SX1276 > > and SX1301 need the soft-MAC. > > On the SX1301 side of things, the ability to send messages as a LoRaWAN > node device is a niche use case, the majority if not all people will use the > concentrator card as the pass through gateway to the node. > > In this mode of operation the parameters for transmission such as; frequency, > spreading factor / data rate, power, are given by a remote server and passed > in from the userspace application which received it. > Eventually in the kernel these need to be checked locally to ensure regulatory > compliance. > To that end I have experimented with framing, as CAN does, so that this > metadata can be provided on a write from userspace to the SX1301 driver. > &g
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> Tue, Dec 18, 2018 at 03:27:09PM CET, starni...@g.ncu.edu.tw wrote: > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > >> >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices. > >> > > >> >This patch implements part of Class A end-devices SoftMAC defined in > >> >LoRaWAN(TM) Specification Ver. 1.0.2: > >> >1. End-device receive slot timing > >> >2. Only single channel and single data rate for now > >> >3. Unconfirmed data up/down message types > >> > > >> >On the other side, it defines the basic interface and operation > >> >functions for compatible LoRa device drivers. > >> > > >> >Signed-off-by: Jian-Hong Pan > >> >--- > >> >V2: > >> >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and > >> > LoRaWAN Soft MAC modules > >> >- Modify for Big/Little-Endian > >> >- Use SPDX license identifiers > >> > > >> >V3: > >> >- Remove the decoration word - inline of the functions > >> >- Order local variables from longest to shortest line in the functions > >> >- Change the calling mac_cb function to lrw_get_mac_cb macro > >> > > >> >V4: > >> >- Fix the delay period between RX window#1 and window#2 > >> >- Fix by coding style report from scripts/checkpatch.pl > >> > > >> >V5: > >> >- Initial rx_skb_list when it is allocated with LoRa hardware > >> >- Check the sk_buff's data length before access it > >> >- Deal FPort field and decrypt payload in lrw_parse_frame function > >> >- Drop the recieved frame if parse failed > >> >- Fix the bug which passes wrong skb properties from maclorawan to > >> >lorawan module > >> > > >> > net/maclorawan/Kconfig | 14 + > >> > net/maclorawan/Makefile | 2 + > >> > net/maclorawan/mac.c| 555 > >> > net/maclorawan/main.c | 606 > >> > 4 files changed, 1177 insertions(+) > >> > create mode 100644 net/maclorawan/Kconfig > >> > create mode 100644 net/maclorawan/Makefile > >> > create mode 100644 net/maclorawan/mac.c > >> > create mode 100644 net/maclorawan/main.c > >> > >> > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > >> you add headers for "API" and here you implement functions. That is just > >> weird. Does it mean you can have other implementations? > > > >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > >This part is soft-MAC as Andreas mentioned > >http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html > > Okay, that does not answer my concern about header file in one patch and > the actual implementation of functions in another one. Just for clarification: - Patch "net: lorawan: Add LoRaWAN socket module" is for lorawan module - Patch "net: lorawan: Add LoRaWAN API declaration for LoRa devices" containes the header file "include/linux/lora/lorawan.h" which will be included by LoRa device drivers or other kernel modules. - Patches "net: maclorawan: Add maclorawan module declaration", "net: maclorawan: Implement the crypto of maclorawan module" and "net: maclorawan: Implement maclorawan class module" are for maclorawan module. Question 1: Should I marge "net: maclorawan: Add maclorawan module declaration", "net: maclorawan: Implement the crypto of maclorawan module" and "net: maclorawan: Implement maclorawan class module" into a single patch named "net: maclorawan: Add maclorawan as the soft-MAC module"? Then: For example, after a LoRa device driver includes the header "linux/lora/lorawan.h", the device driver will call "lrw_alloc_hw()" and pass with a "struct lrw_operations" type of variable's pointer. It gets a type of "struct lrw_hw *" pointer. Then, it will call "lrw_register_hw()" to register the device. The device driver implements the callback functions for the "struct lrw_operations" type of variable by it self before calls "lrw_alloc_hw()". Question 2: Should the patch "net: lorawan: Add LoRaWAN API declaration for LoRa devices" also be merged into "net: maclorawan: Add maclorawan as the soft-MAC module" or "net: maclorawan: Implement maclorawan class module"? Or, just leave it as a single patch?
Re: [PATCH v5 5/6] net: maclorawan: Implement maclorawan class module
> Sun, Dec 16, 2018 at 11:18:59AM CET, starni...@g.ncu.edu.tw wrote: > >LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices. > > > >This patch implements part of Class A end-devices SoftMAC defined in > >LoRaWAN(TM) Specification Ver. 1.0.2: > >1. End-device receive slot timing > >2. Only single channel and single data rate for now > >3. Unconfirmed data up/down message types > > > >On the other side, it defines the basic interface and operation > >functions for compatible LoRa device drivers. > > > >Signed-off-by: Jian-Hong Pan > >--- > >V2: > >- Split the LoRaWAN class module patch in V1 into LoRaWAN socket and > > LoRaWAN Soft MAC modules > >- Modify for Big/Little-Endian > >- Use SPDX license identifiers > > > >V3: > >- Remove the decoration word - inline of the functions > >- Order local variables from longest to shortest line in the functions > >- Change the calling mac_cb function to lrw_get_mac_cb macro > > > >V4: > >- Fix the delay period between RX window#1 and window#2 > >- Fix by coding style report from scripts/checkpatch.pl > > > >V5: > >- Initial rx_skb_list when it is allocated with LoRa hardware > >- Check the sk_buff's data length before access it > >- Deal FPort field and decrypt payload in lrw_parse_frame function > >- Drop the recieved frame if parse failed > >- Fix the bug which passes wrong skb properties from maclorawan to lorawan > >module > > > > net/maclorawan/Kconfig | 14 + > > net/maclorawan/Makefile | 2 + > > net/maclorawan/mac.c| 555 > > net/maclorawan/main.c | 606 > > 4 files changed, 1177 insertions(+) > > create mode 100644 net/maclorawan/Kconfig > > create mode 100644 net/maclorawan/Makefile > > create mode 100644 net/maclorawan/mac.c > > create mode 100644 net/maclorawan/main.c > > > I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > you add headers for "API" and here you implement functions. That is just > weird. Does it mean you can have other implementations? LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. This part is soft-MAC as Andreas mentioned http://lists.infradead.org/pipermail/linux-lpwan/2018-December/10.html > Also, you don't really have any user of this API in the set. Please > introduce at least 1 driver, preferably more (I see that Andreas has > multiple ones in his patchset). You cannot push kernel infrastructure > without kernel user. The soft-MAC is suitable for the LoRa chips' device drivers, like sx1276/77/78/79, RFM95/96/97/98W ... Still waiting for Andreas' sx1276 version 2 patch and more discussion. For example, how to make PF_LORA and PF_LORAWAN like Ethernet, PF_INET and PF_INET6 don't need separate devices either, both use eth0. https://lkml.org/lkml/2018/8/3/266 Jian-Hong Pan
