* [PATCH v5 03/14] KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
From: Marc Zyngier @ 2018-05-08 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525449935-31424-4-git-send-email-Dave.Martin@arm.com>
On 04/05/18 17:05, Dave Martin wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> KVM/ARM differs from other architectures in having to maintain an
> additional virtual address space from that of the host and the
> guest, because we split the execution of KVM across both EL1 and
> EL2.
>
> This results in a need to explicitly map data structures into EL2
> (hyp) which are accessed from the hyp code. As we are about to be
> more clever with our FPSIMD handling on arm64, which stores data in
> the task struct and uses thread_info flags, we will have to map
> parts of the currently executing task struct into the EL2 virtual
> address space.
>
> However, we don't want to do this on every KVM_RUN, because it is a
> fairly expensive operation to walk the page tables, and the common
> execution mode is to map a single thread to a VCPU. By introducing
> a hook that architectures can select with
> HAVE_KVM_VCPU_RUN_PID_CHANGE, we do not introduce overhead for
> other architectures, but have a simple way to only map the data we
> need when required for arm64.
>
> This patch introduces the framework only, and wires it up in the
> arm/arm64 KVM common code.
>
> No functional change.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv2 3/3] arm64: dts: stratix10: add sdram ecc
From: Borislav Petkov @ 2018-05-08 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADhT+weL=8ODk1JVLwUXtFG3e4iKfzBMpZmo4Y0UwoK0=H=Zhg@mail.gmail.com>
On Mon, May 07, 2018 at 04:10:01PM -0500, Dinh Nguyen wrote:
> Do you mind if I take this patch through arm-soc?
Sure, but you have to give me an immutable branch which I can merge into
my tree so that the functionality in 2/3 can get used when it lands in
linux-next and later in mainline.
So please take it and give me the tag (I see you're using tags) which
you're sending up.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH] ASoC: uniphier: evea: use DAPM to change source of line-in
From: Katsuhiro Suzuki @ 2018-05-08 8:45 UTC (permalink / raw)
To: linux-arm-kernel
This patch replaces mixer switch to DAPM one for changing audio source
of line-in.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
sound/soc/uniphier/evea.c | 55 +++++++++++++++++++++++----------------
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/sound/soc/uniphier/evea.c b/sound/soc/uniphier/evea.c
index 73fd6730095c..f9c10165fbc1 100644
--- a/sound/soc/uniphier/evea.c
+++ b/sound/soc/uniphier/evea.c
@@ -54,8 +54,21 @@ struct evea_priv {
int switch_hp;
};
+static const char * const linsw1_sel1_text[] = {
+ "LIN1", "LIN2", "LIN3"
+};
+
+static SOC_ENUM_SINGLE_DECL(linsw1_sel1_enum,
+ ALINSW1, ALINSW1_SEL1_SHIFT,
+ linsw1_sel1_text);
+
+static const struct snd_kcontrol_new linesw1_mux[] = {
+ SOC_DAPM_ENUM("Line In 1 Source", linsw1_sel1_enum),
+};
+
static const struct snd_soc_dapm_widget evea_widgets[] = {
- SND_SOC_DAPM_ADC("ADC", "Capture", SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_ADC("ADC", NULL, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_MUX("Line In 1 Mux", SND_SOC_NOPM, 0, 0, linesw1_mux),
SND_SOC_DAPM_INPUT("LIN1_LP"),
SND_SOC_DAPM_INPUT("LIN1_RP"),
SND_SOC_DAPM_INPUT("LIN2_LP"),
@@ -63,7 +76,9 @@ static const struct snd_soc_dapm_widget evea_widgets[] = {
SND_SOC_DAPM_INPUT("LIN3_LP"),
SND_SOC_DAPM_INPUT("LIN3_RP"),
- SND_SOC_DAPM_DAC("DAC", "Playback", SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC("DAC HP", NULL, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC("DAC LO1", NULL, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC("DAC LO2", NULL, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_OUTPUT("HP1_L"),
SND_SOC_DAPM_OUTPUT("HP1_R"),
SND_SOC_DAPM_OUTPUT("LO2_L"),
@@ -71,17 +86,22 @@ static const struct snd_soc_dapm_widget evea_widgets[] = {
};
static const struct snd_soc_dapm_route evea_routes[] = {
- { "ADC", NULL, "LIN1_LP" },
- { "ADC", NULL, "LIN1_RP" },
- { "ADC", NULL, "LIN2_LP" },
- { "ADC", NULL, "LIN2_RP" },
- { "ADC", NULL, "LIN3_LP" },
- { "ADC", NULL, "LIN3_RP" },
-
- { "HP1_L", NULL, "DAC" },
- { "HP1_R", NULL, "DAC" },
- { "LO2_L", NULL, "DAC" },
- { "LO2_R", NULL, "DAC" },
+ { "Line In 1", NULL, "ADC" },
+ { "ADC", NULL, "Line In 1 Mux" },
+ { "Line In 1 Mux", "LIN1", "LIN1_LP" },
+ { "Line In 1 Mux", "LIN1", "LIN1_RP" },
+ { "Line In 1 Mux", "LIN2", "LIN2_LP" },
+ { "Line In 1 Mux", "LIN2", "LIN2_RP" },
+ { "Line In 1 Mux", "LIN3", "LIN3_LP" },
+ { "Line In 1 Mux", "LIN3", "LIN3_RP" },
+
+ { "DAC HP", NULL, "Headphone 1" },
+ { "DAC LO1", NULL, "Line Out 1" },
+ { "DAC LO2", NULL, "Line Out 2" },
+ { "HP1_L", NULL, "DAC HP" },
+ { "HP1_R", NULL, "DAC HP" },
+ { "LO2_L", NULL, "DAC LO2" },
+ { "LO2_R", NULL, "DAC LO2" },
};
static void evea_set_power_state_on(struct evea_priv *evea)
@@ -280,16 +300,7 @@ static int evea_set_switch_hp(struct snd_kcontrol *kcontrol,
return evea_update_switch_hp(evea);
}
-static const char * const linsw1_sel1_text[] = {
- "LIN1", "LIN2", "LIN3"
-};
-
-static SOC_ENUM_SINGLE_DECL(linsw1_sel1_enum,
- ALINSW1, ALINSW1_SEL1_SHIFT,
- linsw1_sel1_text);
-
static const struct snd_kcontrol_new evea_controls[] = {
- SOC_ENUM("Line Capture Source", linsw1_sel1_enum),
SOC_SINGLE_BOOL_EXT("Line Capture Switch", 0,
evea_get_switch_lin, evea_set_switch_lin),
SOC_SINGLE_BOOL_EXT("Line Playback Switch", 0,
--
2.17.0
^ permalink raw reply related
* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: James Morse @ 2018-05-08 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505122719.GE3708@pd.tnic>
Hi Borislav,
On 05/05/18 13:27, Borislav Petkov wrote:
> On Fri, Apr 27, 2018 at 04:35:05PM +0100, James Morse wrote:
>> Arm64 has multiple NMI-like notifications, but ghes.c only has one
>> in_nmi() path, risking deadlock if one NMI-like notification can
>> interrupt another.
>>
>> To support this we need a fixmap entry and lock for each notification
>> type. But ghes_probe() attempts to process each struct ghes at probe
>> time, to ensure any error that was notified before ghes_probe() was
>> called has been done, and the buffer released (and maybe acknowledge
>> to firmware) so that future errors can be delivered.
>>
>> This means NMI-like notifications need two fixmap entries and locks,
>> one for the ghes_probe() time call, and another for the actual NMI
>> that could interrupt ghes_probe().
>>
>> Split this single path up by adding an NMI fixmap idx and lock into
>> the struct ghes. Any notification that can be called as an NMI can
>> use these to separate its resources from any other notification it
>> may interrupt.
>>
>> The majority of notifications occur in IRQ context, so unless its
>> called in_nmi(), ghes_copy_tofrom_phys() will use the FIX_APEI_GHES_IRQ
>> fixmap entry and the ghes_fixmap_lock_irq lock. This allows
>> NMI-notifications to be processed by ghes_probe(), and then taken
>> as an NMI.
>>
>> The double-underscore version of fix_to_virt() is used because the index
>> to be mapped can't be tested against the end of the enum at compile
>> time.
>> @@ -986,6 +960,8 @@ int ghes_notify_sea(void)
>>
>> static void ghes_sea_add(struct ghes *ghes)
>> {
>> + ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
>> + ghes->nmi_fixmap_idx = FIX_APEI_GHES_NMI;
>> ghes_estatus_queue_grow_pool(ghes);
>>
>> mutex_lock(&ghes_list_mutex);
>> @@ -1032,6 +1008,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
>>
>> static void ghes_nmi_add(struct ghes *ghes)
>> {
>> + ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
>
> Ewww, we're assigning the spinlock to a pointer which we'll take later?
> Yuck.
> Why?
So that APEI doesn't need to know which lock goes with which fixmap page, and
how these notifications interact.
> Do I see it correctly that one can have ACPI_HEST_NOTIFY_SEA and
> ACPI_HEST_NOTIFY_NMI coexist in parallel on a single system?
NOTIFY_NMI is x86's NMI, arm doesn't have anything that behaves in the same way,
so doesn't use it. The equivalent notifications with NMI-like behaviour are:
* SEA (synchronous external abort)
* SEI (SError Interrupt)
* SDEI (software delegated exception interface)
> If not, you can use a single spinlock.
Today we could, but once we have SDEI and SEI this won't work:
SDEI behaves as two notifications, 'normal' and 'critical', a different fixmap
page is needed for these as they can interrupt each other, and a different lock.
SEA can interrupt SEI, so they need a different fixmap-pages and locks.
We can always disable SEI when we're handling another NMI-like notification.
I doubt anyone would implement all three, but if they did SEA can interrupt the lot.
I'd like to avoid describing any of these interactions in ghes.c, I think it
should be possible that any notification can interrupt any other notification
without the risk of deadlock.
> If yes, then I'd prefer to make it less ugly and do the notification
> type check ghes_probe() does:
>
> switch (generic->notify.type)
>
> and take the respective spinlock in ghes_copy_tofrom_phys(). This way it
> is a bit better than using a spinlock ptr.
I wanted to avoid duplicating that list, some of the locks are #ifdef'd so it
gets ugly quickly. (We would only need the NMI-like notifications though).
I'd really like to avoid the GHES code having to know about normal/critical SDEI
events.
Alternatively, I can put the fixmap-page and spinlock in some 'struct
ghes_notification' that only the NMI-like struct-ghes need. This is just moving
the indirection up a level, but it does pair the lock with the thing it locks,
and gets rid of assigning spinlock pointers.
Thanks,
James
^ permalink raw reply
* [PATCH 4/5] arm64: allwinner: h6: add USB3 device nodes
From: Sergei Shtylyov @ 2018-05-08 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507151817.55663-5-icenowy@aosc.io>
Hello!
On 5/7/2018 6:18 PM, Icenowy Zheng wrote:
> Allwinner H6 SoC features USB3 functionality, with a DWC3 controller and
> a custom PHY.
>
> Add device tree nodes for them.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 ++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index c72da8cd9ef5..9564c938717c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -174,6 +174,44 @@
> status = "disabled";
> };
>
> + usb3: usb at 5200000 {
I don't think <unit-address> is allowed for a node having no "reg" prop...
> + compatible = "allwinner,sun50i-h6-dwc3";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + clocks = <&ccu CLK_BUS_XHCI>;
> + clock-names = "bus";
> + resets = <&ccu RST_BUS_XHCI>;
> + reset-names = "bus";
> + status = "disabled";
> +
> + dwc3: dwc3 {
Contrariwise, need <unit-address> here...
> + compatible = "snps,dwc3";
> + reg = <0x5200000 0x10000>;
> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> + /*
> + * According to Wink from Allwinner, the
> + * USB3 port on H6 is not capable of OTG;
> + * the datasheet doesn't mention OTG at all
> + * either, so the dr_mode is default to
> + * "host" here.
> + */
> + dr_mode = "host";
> + phys = <&usb3phy>;
> + phy-names = "usb3-phy";
> + status = "disabled";
> + };
> + };
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang @ 2018-05-08 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D474053D-6910-4B04-8B98-59B96FEB86BC@holtmann.org>
Hi, Marcel
On Tue, 2018-05-08 at 09:27 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>> +
> >>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
> >>> + const void *param)
> >>> +{
> >>> + struct mtk_bt_dev *btdev = hu->priv;
> >>> + struct hci_command_hdr *hhdr;
> >>> + struct hci_acl_hdr *ahdr;
> >>> + struct mtk_wmt_hdr *whdr;
> >>> + struct sk_buff *skb;
> >>> + int ret = 0;
> >>> +
> >>> + init_completion(&btdev->wmt_cmd);
> >>> +
> >>> + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
> >>> + if (!skb)
> >>> + return -ENOMEM;
> >>> +
> >>> + /*
> >>> + * WMT data is carried in either ACL or HCI format with op code as
> >>> + * 0xfc6f and followed by a WMT header and its actual payload.
> >>> + */
> >>
> >> Please use net subsystem comment style.
> >>
> >>> + switch (opcode) {
> >>> + case MTK_WMT_PATCH_DWNLD:
> >>> + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
> >>> + ahdr->handle = cpu_to_le16(0xfc6f);
> >>> + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
> >>> + break;
> >>> + default:
> >>> + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
> >>> + hhdr->opcode = cpu_to_le16(0xfc6f);
> >>> + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
> >>> + break;
> >>> + }
> >>> +
> >>> + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
> >>> + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
> >>
> >> Why not move that into the switch statement above.
> >>
> >>> +
> >>> + /* Start to build a WMT header and its actual payload. */
> >>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> >>> + whdr->dir = 1;
> >>> + whdr->op = opcode;
> >>> + whdr->dlen = cpu_to_le16(plen + 1);
> >>> + whdr->flag = flag;
> >>> + skb_put_data(skb, param, plen);
> >>> +
> >>> + mtk_enqueue(hu, skb);
> >>> + hci_uart_tx_wakeup(hu);
> >>> +
> >>> + /*
> >>> + * Waiting a WMT event response, while we must take care in case of
> >>> + * failures for the wait.
> >>> + */
> >>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> >>> +
> >>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> >>> +}
> >>
> >> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
> >>
> >
> > While i was trying to rewrite the driver based on btuart.c. you posted
> > on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
> > hci command sending which I've done previously with mtk_wmt_cmd_sync.
> >
> > However, eventually, I got a cmd_timer timeout whose message printed
> > on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
> >
> > The mtk soc specific cmd/event I posted below, I dumped directly in
> > driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
> >
> > It appears to the event id is not standard and thus it cannot cancel the
> > cmd timer when the special hci event is being handled. This way can we
> > can still use __hci_cmd_sync api ?
> >
> > [ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
> > [ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
> > 00
> > [ 4.912859] Bluetooth: hci0 event 0xe4
> >
> >
> > buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
> > timeout
> > [ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
> > 01 .o........
> > [ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
> > 00 .......
> > [ 7.014821] Bluetooth: hci0 event 0xe4
>
> can you just start btmon before loading the module / driver? It makes it a lot easier since it will actually decode the basics for us. If there is a bug within __hci_cmd_sync_ev, then we are going to fix it.
>
I'm happy to do with btmon. just the environment with buildroot the BT
running on seems there's a missing support for btmon. I can start to use
btmon once I change the environment to Debian.
> So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
>
yes, mtk controller after mt7622 (included), its MTK vendors command
(opcode 0xfc6f) always respond with a vendor event id 0xe4. And they
don't do any standard status/complete handling.
BTW, mtk controller before mt7622, such as mt7623, its MTK vendor
command always go with completely specific format, not with hci format.
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH 4.14 42/43] irqchip/qcom: Fix check for spurious interrupts
From: Greg Kroah-Hartman @ 2018-05-08 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508074003.984433784@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
^ permalink raw reply
* [PATCH 4.16 48/52] irqchip/qcom: Fix check for spurious interrupts
From: Greg Kroah-Hartman @ 2018-05-08 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508073928.058320984@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
^ permalink raw reply
* [PATCH v9 07/12] ARM: sunxi: Add initialization of CNTVOFF
From: Marc Zyngier @ 2018-05-08 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-8-mylene.josserand@bootlin.com>
On 04/05/18 20:05, Myl?ne Josserand wrote:
> Add the initialization of CNTVOFF for sun8i-a83t.
>
> For boot CPU, create a new machine that handles this
> function's call in an "init_early" callback. We need to initialize
> CNTVOFF before the arch timer's initialization otherwise, it will
> not be taken into account and fails to boot correctly.
> Because of that, this function can't be called in SMP's early_initcall
> function which is called after timer's init.
>
> For secondary CPUs, add this function into secondary_startup
> assembly entry.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v9 06/12] ARM: smp: Add initialization of CNTVOFF
From: Marc Zyngier @ 2018-05-08 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-7-mylene.josserand@bootlin.com>
On 04/05/18 20:05, Myl?ne Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
>
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PACTCH v5 1/2] ARM: dts: imx: Add basic dtsi file for imx6sll
From: Jacky Bai @ 2018-05-08 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502065513.GA3443@dragon>
> Subject: Re: [PACTCH v5 1/2] ARM: dts: imx: Add basic dtsi file for imx6sll
>
> On Fri, Apr 13, 2018 at 04:01:03PM +0800, Bai Ping wrote:
> > Add dtsi file for imx6sll.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > change v3->v4
> > - update the license indentifier
> > - remove leading zeros of node
> > - move pin header to this patch
> > change v4->v5
> > - use generic name for device node
> > ---
> > arch/arm/boot/dts/imx6sll-pinfunc.h | 880
> ++++++++++++++++++++++++++++++++++++
> > arch/arm/boot/dts/imx6sll.dtsi | 802
> ++++++++++++++++++++++++++++++++
> > 2 files changed, 1682 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6sll-pinfunc.h
> > create mode 100644 arch/arm/boot/dts/imx6sll.dtsi
>
> <snip>
>
> > +
> > + epit1: epit at 20d0000 {
> > + reg = <0x020d0000 0x4000>;
> > + interrupts = <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + epit2: epit at 20d4000 {
> > + reg = <0x020d4000 0x4000>;
> > + interrupts = <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + };
>
> 'timer' for node name. If these devices are not used, I would even suggest
> to drop them.
>
ok, will drop these node.
> > +
> > + src: reset-controller at 20d8000 {
> > + compatible = "fsl,imx6sll-src";
> > + reg = <0x020d8000 0x4000>;
> > + interrupts = <GIC_SPI 91
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 96
> IRQ_TYPE_LEVEL_HIGH>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + gpc: interrupt-controller at 20dc000 {
> > + compatible = "fsl,imx6sll-gpc", "fsl,imx6q-
> gpc";
> > + reg = <0x020dc000 0x4000>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + interrupts = <GIC_SPI 89
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-parent = <&intc>;
> > + fsl,mf-mix-wakeup-irq = <0x7c00000 0x7d00
> 0x0 0x1400640>;
> > + };
> > +
> > + iomuxc: pinctrl at 20e0000 {
> > + compatible = "fsl,imx6sll-iomuxc";
> > + reg = <0x020e0000 0x4000>;
> > + };
> > +
> > + gpr: iomuxc-gpr at 20e4000 {
> > + compatible = "fsl,imx6sll-iomuxc-gpr",
> > + "fsl,imx6q-iomuxc-gpr", "syscon";
> > + reg = <0x020e4000 0x4000>;
> > + };
> > +
> > + csi: csi at 20e8000 {
> > + compatible = "fsl,imx6sll-csi", "fsl,imx6s-csi";
> > + reg = <0x020e8000 0x4000>;
> > + interrupts = <GIC_SPI 7
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DUMMY>,
> > + <&clks IMX6SLL_CLK_CSI>,
> > + <&clks IMX6SLL_CLK_DUMMY>;
> > + clock-names = "disp-axi", "csi_mclk",
> "disp_dcic";
> > + status = "disabled";
> > + };
> > +
> > + sdma: dma-controller at 20ec000 {
> > + compatible = "fsl,imx6sll-sdma", "fsl,imx35-
> sdma";
> > + reg = <0x020ec000 0x4000>;
> > + interrupts = <GIC_SPI 2
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_SDMA>,
> > + <&clks IMX6SLL_CLK_SDMA>;
> > + clock-names = "ipg", "ahb";
> > + #dma-cells = <3>;
> > + iram = <&ocram>;
> > + fsl,sdma-ram-script-name =
> "imx/sdma/sdma-imx6q.bin";
> > + };
> > +
> > + lcdif: lcd-controller at 20f8000 {
> > + compatible = "fsl,imx6sll-lcdif", "fsl,imx28-
> lcdif";
> > + reg = <0x020f8000 0x4000>;
> > + interrupts = <GIC_SPI 39
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_LCDIF_PIX>,
> > + <&clks IMX6SLL_CLK_LCDIF_APB>,
> > + <&clks IMX6SLL_CLK_DUMMY>;
> > + clock-names = "pix", "axi", "disp_axi";
> > + status = "disabled";
> > + };
> > +
> > + dcp: dcp at 20fc000 {
> > + compatible = "fsl,imx6sl-dcp";
>
> Is the compatible supported/documented?
It is compatible with imx28, I will change this compatible to " fsl,imx28-dcp "
>
> > + reg = <0x020fc000 0x4000>;
> > + interrupts = <GIC_SPI 99
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 100
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DCP>;
> > + clock-names = "dcp";
> > + };
> > + };
> > +
> > + aips2: aips-bus at 2100000 {
> > + compatible = "fsl,aips-bus", "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0x02100000 0x100000>;
> > + ranges;
> > +
> > + usbotg1: usb at 2184000 {
> > + compatible = "fsl,imx6sll-usb", "fsl,imx6ul-
> usb",
> > + "fsl,imx27-usb";
> > + reg = <0x02184000 0x200>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USBOH3>;
> > + fsl,usbphy = <&usbphy1>;
> > + fsl,usbmisc = <&usbmisc 0>;
> > + fsl,anatop = <&anatop>;
> > + ahb-burst-config = <0x0>;
> > + tx-burst-size-dword = <0x10>;
> > + rx-burst-size-dword = <0x10>;
> > + status = "disabled";
> > + };
> > +
> > + usbotg2: usb at 2184200 {
> > + compatible = "fsl,imx6sll-usb", "fsl,imx6ul-
> usb",
> > + "fsl,imx27-usb";
> > + reg = <0x02184200 0x200>;
> > + interrupts = <GIC_SPI 42
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USBOH3>;
> > + fsl,usbphy = <&usbphy2>;
> > + fsl,usbmisc = <&usbmisc 1>;
> > + ahb-burst-config = <0x0>;
> > + tx-burst-size-dword = <0x10>;
> > + rx-burst-size-dword = <0x10>;
> > + status = "disabled";
> > + };
> > +
> > + usbmisc: usbmisc at 2184800 {
> > + #index-cells = <1>;
> > + compatible = "fsl,imx6sll-usbmisc",
> "fsl,imx6ul-usbmisc",
> > + "fsl,imx6q-usbmisc";
> > + reg = <0x02184800 0x200>;
> > + };
> > +
> > + usdhc1: mmc at 2190000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02190000 0x4000>;
> > + interrupts = <GIC_SPI 22
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC1>,
> > + <&clks IMX6SLL_CLK_USDHC1>,
> > + <&clks IMX6SLL_CLK_USDHC1>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + usdhc2: mmc at 2194000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02194000 0x4000>;
> > + interrupts = <GIC_SPI 23
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC2>,
> > + <&clks IMX6SLL_CLK_USDHC2>,
> > + <&clks IMX6SLL_CLK_USDHC2>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + usdhc3: mmc at 2198000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02198000 0x4000>;
> > + interrupts = <GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC3>,
> > + <&clks IMX6SLL_CLK_USDHC3>,
> > + <&clks IMX6SLL_CLK_USDHC3>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + i2c1: i2c at 21a0000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fs,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a0000 0x4000>;
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C1>;
> > + status = "disabled";
> > + };
> > +
> > + i2c2: i2c at 21a4000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a4000 0x4000>;
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C2>;
> > + status = "disabled";
> > + };
> > +
> > + i2c3: i2c at 21a8000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a8000 0x4000>;
> > + interrupts = <GIC_SPI 38
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C3>;
> > + status = "disabled";
> > + };
> > +
> > + romcp at 21ac000 {
> > + compatible = "fsl,imx6sll-romcp", "syscon";
>
> The compatible "fsl,imx6sll-romcp" is undocumented. If the device is not
> used by upstream kernel, I would even suggest to drop it.
Ok, will drop it.
>
> > + reg = <0x021ac000 0x4000>;
> > + };
> > +
> > + mmdc: memory-controller at 21b0000 {
> > + compatible = "fsl,imx6sll-mmdc", "fsl,imx6q-
> mmdc";
> > + reg = <0x021b0000 0x4000>;
> > + };
> > +
> > + rngb: rngb at 21b4000 {
>
> Is the device used at all?
will drop it.
>
> > + reg = <0x021b4000 0x4000>;
> > + interrupts = <GIC_SPI 5
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DUMMY>;
> > + };
> > +
> > + ocotp: ocotp-ctrl at 21bc000 {
> > + compatible = "fsl,imx6sll-ocotp", "syscon";
> > + reg = <0x021bc000 0x4000>;
> > + clocks = <&clks IMX6SLL_CLK_OCOTP>;
> > + };
> > +
> > + snvs_gpr: snvs-gpr at 21c4000 {
> > + reg = <0x021c4000 0x10000>;
> > + };
>
> Ditto
>
> > +
> > + iomuxc_snvs: iomuxc-snvs at 21c8000 {
> > + reg = <0x021c8000 0x10000>;
> > + };
>
> Ditto
>
Ok. Will drop these two.
> Shawn
>
> > +
> > + audmux: audmux at 21d8000 {
> > + compatible = "fsl,imx6sll-audmux",
> "fsl,imx31-audmux";
> > + reg = <0x021d8000 0x4000>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial at 21f4000 {
> > + compatible = "fsl,imx6sll-uart", "fsl,imx6q-
> uart",
> > + "fsl,imx21-uart";
> > + reg = <0x021f4000 0x4000>;
> > + interrupts =<GIC_SPI 30
> IRQ_TYPE_LEVEL_HIGH>;
> > + dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
> > + dma-names = "rx", "tx";
> > + clocks = <&clks IMX6SLL_CLK_UART5_IPG>,
> > + <&clks
> IMX6SLL_CLK_UART5_SERIAL>;
> > + clock-names = "ipg", "per";
> > + status = "disabled";
> > + };
> > + };
> > + };
> > +};
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-08 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f79c109-6b0f-000e-569b-1f702e0006d3@axentia.se>
On Mon, May 07, 2018 at 04:24:43PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:59, Peter Rosin wrote:
> > On 2018-05-07 15:39, Daniel Vetter wrote:
> >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >>> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >>>>> The more natural approach would perhaps be to add an drm_bridge_add,
> >>>>> but there are several other bridges that never call drm_bridge_add.
> >>>>> Just removing the drm_bridge_remove is the easier fix.
> >>>>>
> >>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
> >>>>
> >>>> This mess is much bigger. There's 2 pairs of bridge functions:
> >>>>
> >>>> - drm_bridge_attach/detach. Those are meant to be called by the overall
> >>>> drm driver to connect/disconnect a drm_bridge.
> >>>>
> >>>> - drm_bridge_add/remove. These are supposed to be called by the bridge
> >>>> driver itself to register/unregister itself. Maybe we should rename
> >>>> them, since the same issue happens with drm_panel, with the same
> >>>> confusion.
> >>>>
> >>>> I thought someone was working on a cleanup series to fix this mess, but I
> >>>> didn't find anything.
> >>>
> >>> Ok, I just spotted the imbalance and didn't really dig into what
> >>> actually happens in these error paths. Now that I have done so I
> >>> believe that the removed drm_bridge_remove calls causes NULL
> >>> dereferences if/when the error paths are triggered.
> >>>
> >>> So, I don't think this can wait for some bigger cleanup.
> >>>
> >>> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >>> __list_del with NULL in both prev and next since the list member
> >>> is never initialized. prev and next are dereferenced by __list_del
> >>> and you have *boom*
> >>>
> >>> I recommend adding the tag
> >>>
> >>> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>>
> >>> so that stable picks this one up.
> >>
> >> I just wanted to correct your commit message text - the correct solution
> >> is definitely _not_ for sti here to call drm_bridge_add.
> >
> > Ah, I see what you mean. Do you want me to respin?
>
> Hold on, no I don't agree. sti_hda.c does create a bridge for it's own
> internal use. It does not drm_bridge_add it, because all that ever does
> is adding the bridge to the global lost of bridges. But since this is
> a bridge for internal use, there is little point in calling drm_bridge_add,
> the driver currently gains nothing by doing so.
>
> But, drm_bridge_add might be a good place to put common stuff for every
> bridge in the system, so it might be worthwhile to start requiring all
> bridges to be drm_bridge_add-ed. And IMHO, it would not be wrong to have
> the sti-hda driver call drm_bridge_add on the bridge it creates.
>
> Do you really think it is actively wrong to call drm_bridge_add for
> internal bridges such as this?
If we want to share bridge init code, then I think we need a
drm_bridge_init(). Not overload drm_bridge_add (which really should be
drm_bridge_register I think, but oh well, it's at least consistent with
drm_panel_add).
-Daniel
>
> Cheers,
> Peter
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-08 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d378241f-7420-bbaf-c447-18cdfd4f9dd3@axentia.se>
On Mon, May 07, 2018 at 03:59:04PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >>>> The more natural approach would perhaps be to add an drm_bridge_add,
> >>>> but there are several other bridges that never call drm_bridge_add.
> >>>> Just removing the drm_bridge_remove is the easier fix.
> >>>>
> >>>> Signed-off-by: Peter Rosin <peda@axentia.se>
> >>>
> >>> This mess is much bigger. There's 2 pairs of bridge functions:
> >>>
> >>> - drm_bridge_attach/detach. Those are meant to be called by the overall
> >>> drm driver to connect/disconnect a drm_bridge.
> >>>
> >>> - drm_bridge_add/remove. These are supposed to be called by the bridge
> >>> driver itself to register/unregister itself. Maybe we should rename
> >>> them, since the same issue happens with drm_panel, with the same
> >>> confusion.
> >>>
> >>> I thought someone was working on a cleanup series to fix this mess, but I
> >>> didn't find anything.
> >>
> >> Ok, I just spotted the imbalance and didn't really dig into what
> >> actually happens in these error paths. Now that I have done so I
> >> believe that the removed drm_bridge_remove calls causes NULL
> >> dereferences if/when the error paths are triggered.
> >>
> >> So, I don't think this can wait for some bigger cleanup.
> >>
> >> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >> __list_del with NULL in both prev and next since the list member
> >> is never initialized. prev and next are dereferenced by __list_del
> >> and you have *boom*
> >>
> >> I recommend adding the tag
> >>
> >> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>
> >> so that stable picks this one up.
> >
> > I just wanted to correct your commit message text - the correct solution
> > is definitely _not_ for sti here to call drm_bridge_add.
>
> Ah, I see what you mean. Do you want me to respin?
>
> > It should call
> > drm_bridge_attach/detach only, as a pair.
>
> Alas, the attach/detach functions are generally not called from the same
> level. After the bridge has been attached to an encoder, it is detached
> in the generic code shutting down the encoder, i.e. the bridge consumer
> is not explicitly involved with bridge detaching.
>
> > I didn't check whether you instead have a _detach call missing or what's
> > going on here.
>
> So, even though there is no _detach call, it is still not "missing" as
> it is not supposed to be there...
Oh, TIL. Totally missed that we've improved this to be closer to dwim()
semantics. I think your patch is correct as-is and has my
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It'd be great to improve the kerneldoc for drm_bridge_attach though to
mention that bridges get auto-detached on encoder cleanup as don in
drm_encoder_cleanup(). Care to do that?
And on that note I've again realized that most drivers totally get this
wrong when they set their ->destroy callback to drm_encoder_cleanup
(similar for other kms objects), because that one does _not_ do the final
kfree. Oh well.
-Daniel
>
> Cheers,
> Peter
>
> > -Daniel
> >>
> >> Cheers,
> >> Peter
> >>
> >>> -Daniel
> >>>
> >>>> ---
> >>>> drivers/gpu/drm/sti/sti_hda.c | 1 -
> >>>> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >>>> 2 files changed, 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >>>> index 67bbdb49fffc..199db13f565c 100644
> >>>> --- a/drivers/gpu/drm/sti/sti_hda.c
> >>>> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >>>> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >>>> return 0;
> >>>>
> >>>> err_sysfs:
> >>>> - drm_bridge_remove(bridge);
> >>>> return -EINVAL;
> >>>> }
> >>>>
> >>>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> index 58f431102512..932724784942 100644
> >>>> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>>> return 0;
> >>>>
> >>>> err_sysfs:
> >>>> - drm_bridge_remove(bridge);
> >>>> hdmi->drm_connector = NULL;
> >>>> return -EINVAL;
> >>>> }
> >>>> --
> >>>> 2.11.0
> >>>>
> >>>> _______________________________________________
> >>>> dri-devel mailing list
> >>>> dri-devel at lists.freedesktop.org
> >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>>
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Jacky Bai @ 2018-05-08 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56a409cf76a3eaa713cb4f0bbe1e39b6@agner.ch>
> Subject: Re: [PATCH] clk: imx6ull: use OSC clock during AXI rate change
>
> Hi Jacky,
>
> On 02.05.2018 09:38, Shawn Guo wrote:
> > Hi Jacky,
> >
> > Do you see this problem on i.MX6 ULL? What's your take on Stefan's fix?
>
> Any comment to this?
>
> It is 4.17.0-rc4 is out and i.MX 6ULL is still broken :-(
>
Hi Stefan,
I have tried two 6ULL board, I don't meet such issue. System can boot up successfully with commit 6f9575e55632 included.
Anyway, the change in this patch is ok for me. it is no harm to the BUS clock change flow.
Jacky
> --
> Stefan
>
> >
> > Shawn
> >
> > On Wed, Apr 18, 2018 at 02:49:08PM +0200, Stefan Agner wrote:
> >> On i.MX6 ULL using PLL3 seems to cause a freeze when setting the
> >> parent to IMX6UL_CLK_PLL3_USB_OTG. This only seems to appear since
> >> commit 6f9575e55632 ("clk: imx: Add CLK_IS_CRITICAL flag for busy
> >> divider and busy mux"), probably because the clock is now forced to
> >> be on.
> >>
> >> Fixes: 6f9575e55632("clk: imx: Add CLK_IS_CRITICAL flag for busy
> >> divider and busy mux")
> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> ---
> >> This addresses a regression ssen on v4.17-rc1 where the kernel boots
> >> during clock initialization, see also:
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >>
> tchwork.kernel.org%2Fpatch%2F10295927%2F&data=02%7C01%7Cping.bai%
> 40nx
> >>
> p.com%7C023287ec65034c4db45f08d5b419effb%7C686ea1d3bc2b4c6fa92cd9
> 9c5c
> >>
> 301635%7C0%7C0%7C636612945852594725&sdata=U0ZGid9ZBey0FXfId2dhZb
> hVl8p
> >> CcjTiexG3JHYwCA4%3D&reserved=0
> >>
> >> drivers/clk/imx/clk-imx6ul.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/imx/clk-imx6ul.c
> >> b/drivers/clk/imx/clk-imx6ul.c index 114ecbb94ec5..12320118f8de
> >> 100644
> >> --- a/drivers/clk/imx/clk-imx6ul.c
> >> +++ b/drivers/clk/imx/clk-imx6ul.c
> >> @@ -464,7 +464,7 @@ static void __init imx6ul_clocks_init(struct
> device_node *ccm_node)
> >> clk_set_rate(clks[IMX6UL_CLK_AHB], 99000000);
> >>
> >> /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz
> */
> >> - clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
> clks[IMX6UL_CLK_PLL3_USB_OTG]);
> >> + clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
> >> +clks[IMX6UL_CLK_OSC]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
> clks[IMX6UL_CLK_PERIPH_CLK2]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH_PRE],
> clks[IMX6UL_CLK_PLL2_BUS]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
> >> clks[IMX6UL_CLK_PERIPH_PRE]);
> >> --
> >> 2.17.0
> >>
^ permalink raw reply
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Marcel Holtmann @ 2018-05-08 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525762084.14468.20.camel@mtkswgap22>
Hi Sean,
>>> +
>>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
>>> + const void *param)
>>> +{
>>> + struct mtk_bt_dev *btdev = hu->priv;
>>> + struct hci_command_hdr *hhdr;
>>> + struct hci_acl_hdr *ahdr;
>>> + struct mtk_wmt_hdr *whdr;
>>> + struct sk_buff *skb;
>>> + int ret = 0;
>>> +
>>> + init_completion(&btdev->wmt_cmd);
>>> +
>>> + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
>>> + if (!skb)
>>> + return -ENOMEM;
>>> +
>>> + /*
>>> + * WMT data is carried in either ACL or HCI format with op code as
>>> + * 0xfc6f and followed by a WMT header and its actual payload.
>>> + */
>>
>> Please use net subsystem comment style.
>>
>>> + switch (opcode) {
>>> + case MTK_WMT_PATCH_DWNLD:
>>> + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
>>> + ahdr->handle = cpu_to_le16(0xfc6f);
>>> + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
>>> + break;
>>> + default:
>>> + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
>>> + hhdr->opcode = cpu_to_le16(0xfc6f);
>>> + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
>>> + break;
>>> + }
>>> +
>>> + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
>>> + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
>>
>> Why not move that into the switch statement above.
>>
>>> +
>>> + /* Start to build a WMT header and its actual payload. */
>>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
>>> + whdr->dir = 1;
>>> + whdr->op = opcode;
>>> + whdr->dlen = cpu_to_le16(plen + 1);
>>> + whdr->flag = flag;
>>> + skb_put_data(skb, param, plen);
>>> +
>>> + mtk_enqueue(hu, skb);
>>> + hci_uart_tx_wakeup(hu);
>>> +
>>> + /*
>>> + * Waiting a WMT event response, while we must take care in case of
>>> + * failures for the wait.
>>> + */
>>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
>>> +
>>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
>>> +}
>>
>> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
>>
>
> While i was trying to rewrite the driver based on btuart.c. you posted
> on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
> hci command sending which I've done previously with mtk_wmt_cmd_sync.
>
> However, eventually, I got a cmd_timer timeout whose message printed
> on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
>
> The mtk soc specific cmd/event I posted below, I dumped directly in
> driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
>
> It appears to the event id is not standard and thus it cannot cancel the
> cmd timer when the special hci event is being handled. This way can we
> can still use __hci_cmd_sync api ?
>
> [ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
> [ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
> 00
> [ 4.912859] Bluetooth: hci0 event 0xe4
>
>
> buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
> timeout
> [ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
> 01 .o........
> [ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
> 00 .......
> [ 7.014821] Bluetooth: hci0 event 0xe4
can you just start btmon before loading the module / driver? It makes it a lot easier since it will actually decode the basics for us. If there is a bug within __hci_cmd_sync_ev, then we are going to fix it.
So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
Regards
Marcel
^ permalink raw reply
* Patch "irqchip/qcom: Fix check for spurious interrupts" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-05-08 7:23 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
irqchip/qcom: Fix check for spurious interrupts
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
irqchip-qcom-fix-check-for-spurious-interrupts.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1bc2463cee92ef0e2034c813d5e511adeb58b5fd Mon Sep 17 00:00:00 2001
From: Agustin Vega-Frias <agustinv@codeaurora.org>
Date: Tue, 1 May 2018 10:14:50 -0400
Subject: irqchip/qcom: Fix check for spurious interrupts
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
Patches currently in stable-queue which might be from agustinv at codeaurora.org are
queue-4.16/irqchip-qcom-fix-check-for-spurious-interrupts.patch
^ permalink raw reply
* Patch "irqchip/qcom: Fix check for spurious interrupts" has been added to the 4.14-stable tree
From: gregkh at linuxfoundation.org @ 2018-05-08 7:22 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
irqchip/qcom: Fix check for spurious interrupts
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
irqchip-qcom-fix-check-for-spurious-interrupts.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1bc2463cee92ef0e2034c813d5e511adeb58b5fd Mon Sep 17 00:00:00 2001
From: Agustin Vega-Frias <agustinv@codeaurora.org>
Date: Tue, 1 May 2018 10:14:50 -0400
Subject: irqchip/qcom: Fix check for spurious interrupts
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
Patches currently in stable-queue which might be from agustinv at codeaurora.org are
queue-4.14/irqchip-qcom-fix-check-for-spurious-interrupts.patch
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Yao Chen @ 2018-05-08 7:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds kirin pcie msi feature.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
drivers/pci/dwc/pcie-kirin.c | 38 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..4ef684f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -872,6 +872,8 @@
0x0 0x02000000>;
num-lanes = <1>;
#interrupt-cells = <1>;
+ interrupts = <0 283 4>;
+ interrupts-names = "msi";
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1
&gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a0..2319c9c 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
return 0;
}
+static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
+{
+ struct pcie_port *pp = arg;
+
+ return dw_handle_msi_irq(pp);
+}
+
+static void kirin_pcie_msi_init(struct pcie_port *pp)
+{
+ dw_pcie_msi_init(pp);
+}
+
+static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
+{
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ kirin_pcie_msi_init(pp);
+}
+
static int kirin_pcie_host_init(struct pcie_port *pp)
{
kirin_pcie_establish_link(pp);
+ kirin_pcie_enable_interrupts(pp);
return 0;
}
@@ -448,6 +467,25 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
static int __init kirin_add_pcie_port(struct dw_pcie *pci,
struct platform_device *pdev)
{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ pci->pp.msi_irq = platform_get_irq(pdev, 0);
+ if (!pci->pp.msi_irq) {
+ dev_err(&pdev->dev, "failed to get msi irq\n");
+ return -ENODEV;
+ }
+ ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
+ kirin_pcie_msi_irq_handler,
+ IRQF_SHARED | IRQF_NO_THREAD,
+ "kirin_pcie_msi", &pci->pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request msi irq\n");
+ return ret;
+ }
+ }
+
+ pci->pp.root_bus_nr = -1;
pci->pp.ops = &kirin_pcie_host_ops;
return dw_pcie_host_init(&pci->pp);
--
1.9.1
^ permalink raw reply related
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang @ 2018-05-08 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A7391E5D-2945-415B-8AB1-8DFBF2E65878@holtmann.org>
Hi, Marcel
On Tue, 2018-04-03 at 12:27 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
[ ... ]
> > +
> > +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
> > + const void *param)
> > +{
> > + struct mtk_bt_dev *btdev = hu->priv;
> > + struct hci_command_hdr *hhdr;
> > + struct hci_acl_hdr *ahdr;
> > + struct mtk_wmt_hdr *whdr;
> > + struct sk_buff *skb;
> > + int ret = 0;
> > +
> > + init_completion(&btdev->wmt_cmd);
> > +
> > + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
> > + if (!skb)
> > + return -ENOMEM;
> > +
> > + /*
> > + * WMT data is carried in either ACL or HCI format with op code as
> > + * 0xfc6f and followed by a WMT header and its actual payload.
> > + */
>
> Please use net subsystem comment style.
>
> > + switch (opcode) {
> > + case MTK_WMT_PATCH_DWNLD:
> > + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
> > + ahdr->handle = cpu_to_le16(0xfc6f);
> > + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
> > + break;
> > + default:
> > + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
> > + hhdr->opcode = cpu_to_le16(0xfc6f);
> > + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
> > + break;
> > + }
> > +
> > + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
> > + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
>
> Why not move that into the switch statement above.
>
> > +
> > + /* Start to build a WMT header and its actual payload. */
> > + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> > + whdr->dir = 1;
> > + whdr->op = opcode;
> > + whdr->dlen = cpu_to_le16(plen + 1);
> > + whdr->flag = flag;
> > + skb_put_data(skb, param, plen);
> > +
> > + mtk_enqueue(hu, skb);
> > + hci_uart_tx_wakeup(hu);
> > +
> > + /*
> > + * Waiting a WMT event response, while we must take care in case of
> > + * failures for the wait.
> > + */
> > + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> > +
> > + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> > +}
>
> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
>
While i was trying to rewrite the driver based on btuart.c. you posted
on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
hci command sending which I've done previously with mtk_wmt_cmd_sync.
However, eventually, I got a cmd_timer timeout whose message printed
on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
The mtk soc specific cmd/event I posted below, I dumped directly in
driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
It appears to the event id is not standard and thus it cannot cancel the
cmd timer when the special hci event is being handled. This way can we
can still use __hci_cmd_sync api ?
[ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
[ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
00
[ 4.912859] Bluetooth: hci0 event 0xe4
buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
timeout
[ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
01 .o........
[ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
00 .......
[ 7.014821] Bluetooth: hci0 event 0xe4
^ permalink raw reply
* [PATCH v3 2/3] platform: move the early platform device support to arch/sh
From: Geert Uytterhoeven @ 2018-05-08 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-3-brgl@bgdev.pl>
Hi Bartosz,
On Fri, May 4, 2018 at 3:27 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> SuperH is the only user of the current implementation of early platform
> device support. We want to introduce a more robust approach to early
> probing. As the first step - move all the current early platform code
> to arch/sh.
>
> In order not to export internal drivers/base functions to arch code for
> this temporary solution - copy the two needed routines for driver
> matching from drivers/base/platform.c to arch/sh/drivers/platform_early.c.
>
> Also: call early_platform_cleanup() from subsys_initcall() so that it's
> called after all early devices are probed.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> drivers/clocksource/sh_cmt.c | 7 +
> drivers/clocksource/sh_mtu2.c | 7 +
> drivers/clocksource/sh_tmu.c | 8 +
> drivers/tty/serial/sh-sci.c | 7 +-
> include/linux/platform_device.h | 64 +----
The parts used on contemporary ARM/ARM64 Renesas SoCs look fine to me, so
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 1/6] dt-bindings: define vendor prefix for Wi2Wi, Inc.
From: H. Nikolaus Schaller @ 2018-05-08 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507205455.GA28316@rob-hp-laptop>
HI Rob,
> Am 07.05.2018 um 22:54 schrieb Rob Herring <robh@kernel.org>:
>
> On Thu, May 03, 2018 at 11:35:46AM +0200, H. Nikolaus Schaller wrote:
>> Introduce vendor prefix for Wi2Wi, Inc. for W2SG0004 GPS module
>> and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>
> Applied this one so you don't have to keep sending it.
Thanks and BR,
Nikolaus
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Andrzej Hajda @ 2018-05-08 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507135341.GI12521@phenom.ffwll.local>
On 07.05.2018 15:53, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded. Do we need to go this way?
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
>>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> This is already the case. You currently cannot hotplug a drm_bridge,
> everything must be present.
Are you sure? DRM core is changing quite fast, so maybe I have missed
something, but AFAIK core calls bridge code only if full display
pipeline is created and connector is in connected state.
So adding and removing bridges from inactive pipelines should work if
coded properly.
> I don't think it makes sense to change that
> until we have physically hotpluggable drm_bridges in real hardware.
But kernel core already assumes that device drivers are hot-pluggable
:), even this patch is created to solve issues regarding driver hot
unplugging.
> I
> definitely don't want to refcount stuff to work around driver load
> bonghits on DT platforms, because refcounting is way too hard to get right
> :-)
I am not sure about bridges, but I have successfully (IMO) experimented
with hot (un)plugging panel driver, see panel-samsung-s6e8aa0.c driver
and exynos_drm_dsi.c, panel driver can be safely
plugged/unplugged/replugged without any refcounting (but with help of
mipi_dsi attach/detach callbacks, which are not available for
non-mipi-dsi drivers).
Regards
Andrzej
>
> Afaik there's out-of-tree patches to solve 99% of the driver load fun on
> DT platforms, but because it's not a 100% solution it's blocked since
> forever.
> -Daniel
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>> ---
>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>>> include/drm/drm_bridge.h | 2 ++
>>> 2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>> #include <linux/mutex.h>
>>>
>>> #include <drm/drm_bridge.h>
>>> +#include <drm/drm_device.h>
>>> #include <drm/drm_encoder.h>
>>>
>>> #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>
>>> + if (encoder->dev->dev != bridge->odev) {
>>> + bridge->link = device_link_add(encoder->dev->dev,
>>> + bridge->odev, 0);
>>> + if (!bridge->link) {
>>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> + dev_name(encoder->dev->dev));
>>> + return -EINVAL;
>>> + }
>>> + }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> + if (bridge->link)
>>> + device_link_del(bridge->link);
>>> + bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>
>>> + if (bridge->link)
>>> + device_link_del(bridge->link);
>>> + bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>> }
>>>
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>> * @list: to keep track of all added bridges
>>> * @timings: the timing specification for the bridge, if any (may
>>> * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>> * @funcs: control functions
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> @@ -271,6 +272,7 @@ struct drm_bridge {
>>> struct drm_bridge *next;
>>> struct list_head list;
>>> const struct drm_bridge_timings *timings;
>>> + struct device_link *link;
>>>
>>> const struct drm_bridge_funcs *funcs;
>>> void *driver_private;
>>
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add compatible string for FRWY-LS1012A
From: Bhaskar Upadhaya @ 2018-05-08 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-1-git-send-email-Bhaskar.Upadhaya@nxp.com>
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index cdb9dd7..0517440 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -147,6 +147,10 @@ LS1012A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
+LS1012A ARMv8 based FRWY Board
+Required root node properties:
+ - compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
+
LS1012A ARMv8 based FRDM Board
Required root node properties:
- compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: ls1012a: Add FRWY-LS1012A board support
From: Bhaskar Upadhaya @ 2018-05-08 6:29 UTC (permalink / raw)
To: linux-arm-kernel
FRWY-LS1012A is a different design from LS1012A-FRDM,
but has some common SoC features. Key feature on this
board is Micro SD, USB 3.0, DDR, UART.
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 64 ++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 86e18ad..d116144 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frwy.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
new file mode 100644
index 0000000..f69086d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
@@ -0,0 +1,64 @@
+/*
+ * Device Tree file for NXP LS1012A FRWY Board.
+ *
+ * Copyright 2018 NXP
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "fsl-ls1012a.dtsi"
+
+/ {
+ model = "LS1012A FRWY Board";
+ compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
+
+};
+
+&pcie {
+ status = "okay";
+};
+
+&duart0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 00/13] net: mvpp2: phylink conversion
From: David Miller @ 2018-05-08 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135643.23466-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 4 May 2018 15:56:30 +0200
> Also as the SFP cages on both DB boards can be considered as non-wired,
> the SFP code was reworked to really support when some pins of the SFP
> cage aren't described in the device tree. Also a warning was added when
> no Tx disable pin is available. (Patches 1-3).
I guess there is still discussion about whether fixed-link should be
used for this instead of SFP.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox