* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 6:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Arnd Bergmann, Devicetree List,
Linux Kernel Mailing List, Bjorn Andersson, Sudeep Holla,
Frank Rowand, linux-arm-kernel
In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com>
On 29-05-20, 00:20, Jassi Brar wrote:
> The fact that all these bits are backed by one physical signal makes
I believe that within the IP itself, there must be 32 signals, just
that only one comes out of it all OR'd together. Maybe that can be
verified by writing 0x01 to it multiple times and it should generate
the interrupt only once on the first instance. i.e. writing 1 to any
big again won't raise the interrupt.
> the firmware implement its own mux-demux'ing scheme.
Similar to how the interrupt controllers do it in the kernel, they
receive a single interrupt and then go check its registers/bits to see
which peripheral raised it.
> So the choice was
> between demux and single signal at a time.
Well, the demux is on the firmware side and the kernel may not need to
worry about that, let the platform do it ?
> Had there been one signal
> per bit, the implementation would have definitely been 'efficient'.
I will say 'More efficient', it will still be 'efficient' if we
implement doorbell.
> And the first platform the driver was developed on, required message
> passing over the registers.
I think it was correctly done at that point of time. No doubt about
that.
> So now my approach is to make do with what
> we have...unless it shows in numbers.
ARM's office is closed (lock-down) and he doesn't have remote access
to the board and so was unable to do it until now.
Numbers or no numbers, I don't think there is a question here about
what is the most efficient way of doing it. Doing it in parallel (when
the hardware allows) is surely going to be more efficient. Sending a
signal, getting it processed by the firmware, doing something with it
and then sending an Ack and that being received by kernel will take
time. Why make a queue on the kernel side when we don't have to. :)
> Anyways, if it comes to that, I'd rather a separate "doorbell' driver
> than a driver working in two s/w modes.
I think that would be fine with everyone, if you are fine with that
now (based on plain logic and no numbers), maybe we can get that done
now?
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Jiping Ma @ 2020-05-29 5:57 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, zhe.he, bruce.ashfield, yue.tao, will.deacon,
linux-kernel, paul.gortmaker, catalin.marinas, linux-arm-kernel
In-Reply-To: <20200528075418.GB22156@willie-the-truck>
On 05/28/2020 03:54 PM, Will Deacon wrote:
> On Thu, May 28, 2020 at 09:06:07AM +0800, Jiping Ma wrote:
>> On 05/27/2020 11:19 PM, Mark Rutland wrote:
>>> On Wed, May 27, 2020 at 09:33:00AM +0800, Jiping Ma wrote:
>>>> On 05/26/2020 06:26 PM, Mark Rutland wrote:
>>>>> On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:
>>>> This modification can not fix our issue, we need
>>>> perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32 to judge if it is 32-bit
>>>> task or not,
>>>> then return the correct PC value.
>>> I must be missing something here.
>>>
>>> The core code perf_reg_abi(task) is called with the task being sampled,
>>> and the regs are from the task being sampled. For a userspace sample for
>>> a compat task, compat_user_mode(regs) should be equivalent to the
>>> is_compat_thread(task_thread_info(task)) check.
>>>
>>> What am I missing?
>> This issue caused by PC value is not correct. regs are sampled in function
>> perf_output_sample_regs, that call perf_reg_value(regs, bit) to get PC
>> value.
>> PC value is regs[15] in perf_reg_value() function. it should be regs[32].
>>
>> perf_output_sample_regs(struct perf_output_handle *handle,
>> struct pt_regs *regs, u64 mask)
>> {
>> int bit;
>> DECLARE_BITMAP(_mask, 64);
>>
>> bitmap_from_u64(_mask, mask);
>> for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
>> u64 val;
>>
>> val = perf_reg_value(regs, bit);
>> perf_output_put(handle, val);
>> }
>> }
> Yes, but Mark's point is that checking 'compat_user_mode(regs)' should be
> exactly the same as checking 'perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32'.
> Are you saying that's not the case? If so, please can you provide an example
> of when they are different?
Yes, compat_user_mode(regs) is same with 'perf_reg_abi(current) ==
PERF_SAMPLE_REGS_ABI_32'.
I tested it.
Jiping
>
> Leaving that aside for a second, I also think it's reasonable to question
> whether this whole interface is busted or not. I looked at it last night but
> struggled to work out what it's supposed to do. Consider these three
> scenarios, all under an arm64 kernel:
>
> 1. 64-bit perf + 64-bit application being profiled
> 2. 64-bit perf + 32-bit application being profiled
> 3. 32-bit perf + 32-bit application being profiled
>
> It looks like the current code is a bodge to try to handle both (2) and
> (3) at the same time:
>
> - In case (3), userspace only asks about registers 0-15
> - In case (2), we fudge the higher registers so that 64-bit SP and LR
> hold the 32-bit values as a bodge to allow a 64-bit dwarf unwinder
> to unwind the stack
>
> So the idea behind the patch looks fine because case (3) is expecting the PC
> in register 15 and instead gets 0, but the temptation is to clean this up so
> that cases (2) and (3) report the same data to userspace (along the lines of
> Mark's patch), namely only the first 16 registers with the PC moved down. We
> can only do that if the unwinder is happy, which it might be if it only ever
> looks up dwarf register numbers based on the unwind tables in the binary.
> Somebody would need to dig into that. Otherwise, if it generates unconditional
> references to things like register 30 to grab the link register, then we're
> stuck with the bodge and need to special-case the PC.
>
> Thoughts?
>
> Will
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm:cex7 88/106] drivers/ata/ahci_qoriq.c:217:17: sparse: sparse: incorrect type in argument 1 (different address spaces)
From: kbuild test robot @ 2020-05-29 5:25 UTC (permalink / raw)
To: Peng, Ma,; +Cc: Russell King, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 15389 bytes --]
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git cex7
head: 96bd73e4644e76befe9ab998e070a679ae08388c
commit: 04d1ec3ed831580aadbdac12b36b6158ad80dad4 [88/106] ahci: qoriq: workaround for errata A-379364 on lx2160a
config: openrisc-randconfig-s032-20200528 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-243-gc100a7ab-dirty
git checkout 04d1ec3ed831580aadbdac12b36b6158ad80dad4
# save the attached .config to linux build tree
make W=1 C=1 ARCH=openrisc CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/ata/ahci_qoriq.c:217:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] <asn:2> *[assigned] rcw_base @@
>> drivers/ata/ahci_qoriq.c:217:17: sparse: expected void *addr
>> drivers/ata/ahci_qoriq.c:217:17: sparse: got void [noderef] <asn:2> *[assigned] rcw_base
>> drivers/ata/ahci_qoriq.c:219:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] <asn:2> *[assigned] serdes_base @@
drivers/ata/ahci_qoriq.c:219:17: sparse: expected void *addr
>> drivers/ata/ahci_qoriq.c:219:17: sparse: got void [noderef] <asn:2> *[assigned] serdes_base
>> drivers/ata/ahci_qoriq.c:221:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] <asn:2> *[assigned] dev_con_base @@
drivers/ata/ahci_qoriq.c:221:17: sparse: expected void *addr
>> drivers/ata/ahci_qoriq.c:221:17: sparse: got void [noderef] <asn:2> *[assigned] dev_con_base
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value
include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@
vim +217 drivers/ata/ahci_qoriq.c
103
104 static void fsl_sata_errata_379364(bool select)
105 {
106 int val = 0;
107 void __iomem *rcw_base = NULL;
108 void __iomem *serdes_base = NULL;
109 void __iomem *dev_con_base = NULL;
110
111 if (select) {
112 dev_con_base = ioremap(DEVICE_CONFIG_REG_BASE, PAGE_SIZE);
113 if (!dev_con_base)
114 return;
115
116 val = (readl(dev_con_base + SYS_VER_REG) & GENMASK(7, 4)) >> 4;
117 if (val != LX2160A_VER1)
118 goto dev_unmap;
119
120 /*
121 * Add few msec delay.
122 * Check for corresponding serdes lane RST_DONE .
123 * apply lane reset.
124 */
125
126 serdes_base = ioremap(SERDES2_BASE, PAGE_SIZE);
127 if (!serdes_base)
128 goto dev_unmap;
129
130 rcw_base = ioremap(RCWSR29_BASE, PAGE_SIZE);
131 if (!rcw_base)
132 goto serdes_unmap;
133
134 msleep(20);
135
136 val = (readl(rcw_base) & GENMASK(25, 21)) >> 21;
137
138 switch (val) {
139 case 1:
140 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAC)) &
141 LN_RX_MASK) != LN_RX_RST_DONE)
142 writel(LN_RX_RST, serdes_base +
143 SERDES2_LNAX_RX_CR(SERDES2_LNAC));
144 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAD)) &
145 LN_RX_MASK) != LN_RX_RST_DONE)
146 writel(LN_RX_RST, serdes_base +
147 SERDES2_LNAX_RX_CR(SERDES2_LNAD));
148 break;
149
150 case 4:
151 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAG)) &
152 LN_RX_MASK) != LN_RX_RST_DONE)
153 writel(LN_RX_RST, serdes_base +
154 SERDES2_LNAX_RX_CR(SERDES2_LNAG));
155 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAH)) &
156 LN_RX_MASK) != LN_RX_RST_DONE)
157 writel(LN_RX_RST, serdes_base +
158 SERDES2_LNAX_RX_CR(SERDES2_LNAH));
159 break;
160
161 case 5:
162 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAE)) &
163 LN_RX_MASK) != LN_RX_RST_DONE)
164 writel(LN_RX_RST, serdes_base +
165 SERDES2_LNAX_RX_CR(SERDES2_LNAE));
166 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAF)) &
167 LN_RX_MASK) != LN_RX_RST_DONE)
168 writel(LN_RX_RST, serdes_base +
169 SERDES2_LNAX_RX_CR(SERDES2_LNAF));
170 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAG)) &
171 LN_RX_MASK) != LN_RX_RST_DONE)
172 writel(LN_RX_RST, serdes_base +
173 SERDES2_LNAX_RX_CR(SERDES2_LNAG));
174 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAH)) &
175 LN_RX_MASK) != LN_RX_RST_DONE)
176 writel(LN_RX_RST, serdes_base +
177 SERDES2_LNAX_RX_CR(SERDES2_LNAH));
178 break;
179
180 case 8:
181 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAC)) &
182 LN_RX_MASK) != LN_RX_RST_DONE)
183 writel(LN_RX_RST, serdes_base +
184 SERDES2_LNAX_RX_CR(SERDES2_LNAC));
185 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAD)) &
186 LN_RX_MASK) != LN_RX_RST_DONE)
187 writel(LN_RX_RST, serdes_base +
188 SERDES2_LNAX_RX_CR(SERDES2_LNAD));
189 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAE)) &
190 LN_RX_MASK) != LN_RX_RST_DONE)
191 writel(LN_RX_RST, serdes_base +
192 SERDES2_LNAX_RX_CR(SERDES2_LNAE));
193 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAF)) &
194 LN_RX_MASK) != LN_RX_RST_DONE)
195 writel(LN_RX_RST, serdes_base +
196 SERDES2_LNAX_RX_CR(SERDES2_LNAF));
197 break;
198
199 case 12:
200 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAG)) &
201 LN_RX_MASK) != LN_RX_RST_DONE)
202 writel(LN_RX_RST, serdes_base +
203 SERDES2_LNAX_RX_CR(SERDES2_LNAG));
204 if ((readl(serdes_base + SERDES2_LNAX_RX_CBR(SERDES2_LNAH)) &
205 LN_RX_MASK) != LN_RX_RST_DONE)
206 writel(LN_RX_RST, serdes_base +
207 SERDES2_LNAX_RX_CR(SERDES2_LNAH));
208 break;
209
210 default:
211 break;
212 }
213 } else {
214 return;
215 }
216
> 217 iounmap(rcw_base);
218 serdes_unmap:
> 219 iounmap(serdes_base);
220 dev_unmap:
> 221 iounmap(dev_con_base);
222 }
223
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26505 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-05-29 5:20 UTC (permalink / raw)
To: Rob Herring
Cc: Devicetree List, Arnd Bergmann, Viresh Kumar,
Linux Kernel Mailing List, Bjorn Andersson, Sudeep Holla,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200528192005.GA494874@bogus>
On Thu, May 28, 2020 at 2:20 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> > From: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Hi Rob, Arnd and Jassi,
> >
> > This stuff has been doing rounds on the mailing list since several years
> > now with no agreed conclusion by all the parties. And here is another
> > attempt to get some feedback from everyone involved to close this once
> > and for ever. Your comments will very much be appreciated.
> >
> > The ARM MHU is defined here in the TRM [1] for your reference, which
> > states following:
> >
> > "The MHU drives the signal using a 32-bit register, with all 32
> > bits logically ORed together. The MHU provides a set of
> > registers to enable software to set, clear, and check the status
> > of each of the bits of this register independently. The use of
> > 32 bits for each interrupt line enables software to provide more
> > information about the source of the interrupt. For example, each
> > bit of the register can be associated with a type of event that
> > can contribute to raising the interrupt."
> >
> > On few other platforms, like qcom, similar doorbell mechanism is present
> > with separate interrupt for each of the bits (that's how I understood
> > it), while in case of ARM MHU, there is a single interrupt line for all
> > the 32 bits. Also in case of ARM MHU, these registers and interrupts
> > have 3 copies for different priority levels, i.e. low priority
> > non-secure, high priority non-secure and secure channels.
> >
> > For ARM MHU, both the dt bindings and the Linux driver support 3
> > channels for the different priorities right now and support sending a 32
> > bit data on every transfer in a locked fashion, i.e. only one transfer
> > can be done at once and the other have to wait for it to finish first.
> >
> > Here are the point of view of the parties involved on this subject:
> >
> > Jassi's viewpoint:
> >
> > - Virtualization of channels should be discouraged in software based on
> > specific usecases of the application. This may invite other mailbox
> > driver authors to ask for doing virtualization in their drivers.
> >
> > - In mailbox's terminology, every channel is equivalent to a signal,
> > since there is only one signal generated here by the MHU, there should
> > be only one channel per priority level.
> >
> > - The clients should send data (of just setting 1 bit or many in the 32
> > bit word) using the existing mechanism as the delays due to
> > serialization shouldn't be significant anyway.
> >
> > - The driver supports 90% of the users with the current implementation
> > and it shouldn't be extended to support doorbell and implement two
> > different modes by changing value of #mbox-cells field in bindings.
> >
> > Sudeep (ARM) and myself as well to some extent:
> >
> > - The hardware gives us the capability to write the register in
> > parallel, i.e. we can write 0x800 and 0x400 together without any
> > software locks, and so these 32 bits should be considered as separate
> > channel even if only one interrupt is issued by the hardware finally.
> > This shouldn't be called as virtualization of the channels, as the
> > hardware supports this (as clearly mentioned in the TRM) and it takes
> > care of handling the signal properly.
> >
> > - With serialization, if we use only one channel as today at every
> > priority, if there are 5 requests to send signal to the receiver and
> > the dvfs request is the last one in queue (which may be called from
> > scheduler's hot path with fast switching), it unnecessarily needs to
> > wait for the first four transfers to finish due to the software
> > locking imposed by the mailbox framework. This adds additional delay,
> > maybe of few ms only, which isn't required by the hardware but just by
> > the software and few ms can be important in scheduler's hotpath.
> >
> > - With the current approach it isn't possible to assign different bits
> > (or doorbell numbers) to clients from DT and the only way of doing
> > that without adding new bindings is by extending #mbox-cells to accept
> > a value of 2 as done in this patch.
> >
> > Jassi and Sudeep, I hope I was able to represent both the view points
> > properly here. Please correct me if I have made a mistake here.
> >
> > This is it. It would be nice to get the views of everyone now on this
> > and how should this be handled.
>
> I am perfectly fine with adding another cell which seems appropriate
> here. You can have 5 cells for all I care if that makes sense for
> the h/w. That has nothing to do with the Linux design. Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
>
The fact that all these bits are backed by one physical signal makes
the firmware implement its own mux-demux'ing scheme. So the choice was
between demux and single signal at a time. Had there been one signal
per bit, the implementation would have definitely been 'efficient'.
And the first platform the driver was developed on, required message
passing over the registers. So now my approach is to make do with what
we have...unless it shows in numbers.
Anyways, if it comes to that, I'd rather a separate "doorbell' driver
than a driver working in two s/w modes.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Macpaul Lin @ 2020-05-29 4:32 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Greg Kroah-Hartman, Matthias Brugger
Cc: Mediatek WSD Upstream, linux-usb, linux-kernel, linux-mediatek,
Macpaul Lin, Macpaul Lin, linux-arm-kernel
In-Reply-To: <1590726569-28248-1-git-send-email-macpaul.lin@mediatek.com>
When runtime suspend was enabled, runtime suspend might happened
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
drivers/usb/host/xhci-mtk.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd *shared_hcd = xhci->shared_hcd;
+ pm_runtime_put_sync(&dev->dev);
+ pm_runtime_disable(&dev->dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(&dev->dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
- pm_runtime_put_sync(&dev->dev);
- pm_runtime_disable(&dev->dev);
return 0;
}
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
From: Macpaul Lin @ 2020-05-29 4:29 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Greg Kroah-Hartman, Matthias Brugger
Cc: Mediatek WSD Upstream, linux-usb, linux-kernel, linux-mediatek,
Macpaul Lin, Macpaul Lin, linux-arm-kernel
When runtime suspend was enabled, runtime suspend might happened
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.
Change-Id: I70a5dc8006207caeecbac6955ce8e5345dcc70e6
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
drivers/usb/host/xhci-mtk.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd *shared_hcd = xhci->shared_hcd;
+ pm_runtime_put_sync(&dev->dev);
+ pm_runtime_disable(&dev->dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(&dev->dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
- pm_runtime_put_sync(&dev->dev);
- pm_runtime_disable(&dev->dev);
return 0;
}
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] clk: mediatek: assign the initial value to clk_init_data of mtk_mux
From: Stephen Boyd @ 2020-05-29 4:26 UTC (permalink / raw)
To: Matthias Brugger, Nicolas Boichat, Weiyi Lu
Cc: James Liao, Weiyi Lu, srv_heupstream, linux-kernel, stable,
Fan Chen, linux-mediatek, Owen Chen, linux-clk, linux-arm-kernel
In-Reply-To: <1590560749-29136-1-git-send-email-weiyi.lu@mediatek.com>
Quoting Weiyi Lu (2020-05-26 23:25:49)
> When some new clock supports are introduced, e.g. [1]
> it might lead to an error although it should be NULL because
> clk_init_data is on the stack and it might have random values
> if using without initialization.
> Add the missing initial value to clk_init_data.
>
> [1] https://android-review.googlesource.com/c/kernel/common/+/1278046
>
> Fixes: a3ae549917f1 ("clk: mediatek: Add new clkmux register API")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] clk: mediatek: Add MT6765 clock support
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: CC Hwang, Loda Chou, Mediatek WSD Upstream
In-Reply-To: <1582278742-1626-6-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:22)
> From: Owen Chen <owen.chen@mediatek.com>
>
> Add MT6765 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/5] clk: mediatek: add mt6765 clock IDs
From: Stephen Boyd @ 2020-05-29 4:24 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: CC Hwang, Loda Chou, Mediatek WSD Upstream
In-Reply-To: <1582278742-1626-5-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:21)
> From: Mars Cheng <mars.cheng@mediatek.com>
>
> Add MT6765 clock dt-bindings, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: clock: mediatek: document clk bindings vcodecsys for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:23 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: CC Hwang, Loda Chou, Mediatek WSD Upstream
In-Reply-To: <1582278742-1626-4-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:20)
> This patch adds the binding documentation for vcodecsys.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling
From: Guido Günther @ 2020-05-29 4:23 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Peng Fan, Pengutronix Kernel Team, Sam Ravnborg,
Anson Huang, David Airlie, Shawn Guo, linux-kernel, dri-devel,
Andrzej Hajda, Laurent Pinchart, Daniel Vetter, Lucas Stach,
Robert Chiras, Leonard Crestez, Fabio Estevam, linux-arm-kernel,
NXP Linux Team
In-Reply-To: <20200528195914.GB568887@bogus>
Hi Rob,
On Thu, May 28, 2020 at 01:59:14PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:12PM +0200, Guido Günther wrote:
> > No need to encode the SoC specifics in the bridge driver. For the
> > imx8mq we can use the mux-input-bridge.
>
> You can't just change bindings like this. You'd still have to support
> the "old" way. But IMO, this way is the right way.
My understanding is that binding stability only applies to released
kernels and this binding never was in released kernel yet. Does it still
apply in this case?
Cheers,
-- Guido
>
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 ------
> > 1 file changed, 6 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: clock: mediatek: document clk bindings mipi0a for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:19 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: CC Hwang, Loda Chou, Mediatek WSD Upstream
In-Reply-To: <1582278742-1626-3-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:19)
> This patch adds the binding documentation for mipi0a.
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: clock: mediatek: document clk bindings for Mediatek MT6765 SoC
From: Stephen Boyd @ 2020-05-29 4:19 UTC (permalink / raw)
To: Catalin Marinas, Chunfeng Yun, Evan Green, Fabien Parent,
Joerg Roedel, Macpaul Lin, Marc Zyngier, Mark Rutland, Mars Cheng,
Matthias Brugger, Michael Turquette, Owen Chen, Rob Herring,
Ryder Lee, Sean Wang, Shawn Guo, Weiyi Lu, Will Deacon, Yong Wu,
devicetree, linux-arm-kernel, linux-clk, linux-kernel,
linux-mediatek, mtk01761
Cc: CC Hwang, Loda Chou, Mediatek WSD Upstream
In-Reply-To: <1582278742-1626-2-git-send-email-macpaul.lin@mediatek.com>
Quoting Macpaul Lin (2020-02-21 01:52:18)
> This patch adds the binding documentation for apmixedsys, audsys, camsys,
> imgsys, infracfg, mmsys, pericfg, topckgen
>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:fsl/driver] BUILD SUCCESS e9e4ef9116b12951eaee3f8447ba9bbb40ab3620
From: kbuild test robot @ 2020-05-29 4:08 UTC (permalink / raw)
To: Li Yang; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git fsl/driver
branch HEAD: e9e4ef9116b12951eaee3f8447ba9bbb40ab3620 soc: fsl: dpio: Remove unused inline function qbman_write_eqcr_am_rt_register
elapsed time: 8841m
configs tested: 133
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
xtensa virt_defconfig
arm milbeaut_m10v_defconfig
arm lpd270_defconfig
sh landisk_defconfig
arc allyesconfig
c6x evmc6472_defconfig
mips ath25_defconfig
arm s3c2410_defconfig
sh se7722_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
powerpc ppc64e_defconfig
h8300 defconfig
arm mvebu_v5_defconfig
arc nsim_700_defconfig
arm mvebu_v7_defconfig
mips maltaaprp_defconfig
h8300 h8s-sim_defconfig
arm ebsa110_defconfig
mips lasat_defconfig
sh defconfig
sh j2_defconfig
arm tango4_defconfig
arc nsimosci_hs_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a006-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a004-20200528
i386 randconfig-a001-20200528
i386 randconfig-a002-20200528
i386 randconfig-a006-20200528
i386 randconfig-a003-20200528
i386 randconfig-a005-20200528
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
i386 randconfig-a013-20200528
i386 randconfig-a011-20200528
i386 randconfig-a012-20200528
i386 randconfig-a015-20200528
i386 randconfig-a016-20200528
i386 randconfig-a014-20200528
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allnoconfig
s390 defconfig
s390 allyesconfig
s390 allmodconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allmodconfig
um allnoconfig
um defconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
From: Zenghui Yu @ 2020-05-29 4:07 UTC (permalink / raw)
To: Ali Saidi, Thomas Gleixner, Jason Cooper, Marc Zyngier,
linux-kernel
Cc: benh, zeev, linux-arm-kernel, zorik, dwmw
In-Reply-To: <20200529015501.15771-1-alisaidi@amazon.com>
Hi,
On 2020/5/29 9:55, Ali Saidi wrote:
> If an interrupt is disabled the ITS driver has sent a discard removing
> the DeviceID and EventID from the ITT. After this occurs it can't be
> moved to another collection with a MOVI and a command error occurs if
> attempted. Before issuing the MOVI command make sure that the IRQ isn't
> disabled and change the activate code to try and use the previous
> affinity.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 124251b0ccba..1235dd9a2fb2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1540,7 +1540,11 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> /* don't set the affinity when the target cpu is same as current one */
> if (cpu != its_dev->event_map.col_map[id]) {
> target_col = &its_dev->its->collections[cpu];
> - its_send_movi(its_dev, target_col, id);
> +
> + /* If the IRQ is disabled a discard was sent so don't move */
> + if (!irqd_irq_disabled(d))
> + its_send_movi(its_dev, target_col, id);
It looks to me that if the IRQ is disabled, we mask the enable bit in
the corresponding LPI configuration table entry, but not sending DISCARD
to remove the DevID/EventID mapping. And moving a disabled LPI is
actually allowed by the GIC architecture, right?
> +
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
> @@ -3439,8 +3443,16 @@ static int its_irq_domain_activate(struct irq_domain *domain,
> if (its_dev->its->numa_node >= 0)
> cpu_mask = cpumask_of_node(its_dev->its->numa_node);
>
> - /* Bind the LPI to the first possible CPU */
> - cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
> + /* If the cpu set to a different CPU that is still online use it */
> + cpu = its_dev->event_map.col_map[event];
> +
> + cpumask_and(cpu_mask, cpu_mask, cpu_online_mask);
> +
> + if (!cpumask_test_cpu(cpu, cpu_mask)) {
> + /* Bind the LPI to the first possible CPU */
> + cpu = cpumask_first(cpu_mask);
> + }
I'd like to know what actual problem you had seen and the way to
reproduce it :-)
Thanks,
Zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 4:07 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Arnd Bergmann, Jassi Brar, linux-kernel,
Bjorn Andersson, Sudeep Holla, Frank Rowand, linux-arm-kernel
In-Reply-To: <20200528192005.GA494874@bogus>
On 28-05-20, 13:20, Rob Herring wrote:
> Whether Linux
> requires serializing mailbox accesses is a separate issue. On that side,
> it seems silly to not allow driving the h/w in the most efficient way
> possible.
That's exactly what we are trying to say. The hardware allows us to
write all 32 bits in parallel, without any hardware issues, why
shouldn't we do that ? The delay (which Sudeep will find out, he is
facing issues with hardware access because of lockdown right now)
which may be small in transmitting across a mailbox becomes
significant because of the fact that it happens synchronously and the
receiver will send some sort of acknowledgement (and that depends on
the firmware there) and the kernel needs to wait for it, while the
kernel doesn't really need to. There is no reason IMHO for being
inefficient here while we can do better.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: defconfig: Enable SDM845 video clock controller
From: Bjorn Andersson @ 2020-05-29 3:21 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Anson Huang, Will Deacon, linux-arm-msm, linux-kernel, Li Yang,
Marcin Juszkiewicz, Catalin Marinas, Olof Johansson,
Geert Uytterhoeven, Shawn Guo, linux-arm-kernel
In-Reply-To: <20200522102109.3607-1-stanimir.varbanov@linaro.org>
On Fri 22 May 03:21 PDT 2020, Stanimir Varbanov wrote:
> Enable the build of sdm845 video clock controller by default.
>
Applied
Thanks,
Bjorn
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 03d0189f7d68..4eb7e35d2d7d 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -806,6 +806,7 @@ CONFIG_MSM_GCC_8998=y
> CONFIG_QCS_GCC_404=y
> CONFIG_SDM_GCC_845=y
> CONFIG_SDM_GPUCC_845=y
> +CONFIG_SDM_VIDEOCC_845=y
> CONFIG_SDM_DISPCC_845=y
> CONFIG_SM_GCC_8150=y
> CONFIG_QCOM_HFPLL=y
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Spilt PCIe node to comply with hardware design
From: Ryder Lee @ 2020-05-29 3:05 UTC (permalink / raw)
To: chuanjia.liu
Cc: devicetree, lorenzo.pieralisi, srv_heupstream, linux-pci,
linux-kernel, jianjun.wang, bhelgaas, robh+dt, linux-mediatek,
yong.wu, matthias.bgg, linux-arm-kernel, amurray
In-Reply-To: <20200528061648.32078-1-chuanjia.liu@mediatek.com>
On Thu, 2020-05-28 at 14:16 +0800, chuanjia.liu@mediatek.com wrote:
> There are two independent PCIe controllers in MT2712/MT7622 platform,
> and each of them should contain an independent MSI domain.
>
> In current architecture, MSI domain will be inherited from the root
> bridge, and all of the devices will share the same MSI domain.
> Hence that, the PCIe devices will not work properly if the irq number
> which required is more than 32.
>
> Split the PCIe node for MT2712/MT7622 platform to fix MSI issue and
> comply with the hardware design.
>
> change note:
> v2: change the allocation of mt2712 PCIe MMIO space due to the allcation
> size is not right in v1.
>
> chuanjia.liu (4):
> dt-bindings: PCI: Mediatek: Update PCIe binding
> PCI: mediatek: Use regmap to get shared pcie-cfg base
> arm64: dts: mediatek: Split PCIe node for MT2712/MT7622
> ARM: dts: mediatek: Update mt7629 PCIe node
>
> .../bindings/pci/mediatek-pcie-cfg.yaml | 38 +++++
> .../devicetree/bindings/pci/mediatek-pcie.txt | 144 +++++++++++-------
> arch/arm/boot/dts/mt7629-rfb.dts | 3 +-
> arch/arm/boot/dts/mt7629.dtsi | 23 +--
> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 75 +++++----
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 16 +-
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 6 +-
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 68 ++++++---
> drivers/pci/controller/pcie-mediatek.c | 25 ++-
> 9 files changed, 258 insertions(+), 140 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml
>
> --
> 2.18.0
>
>
For the series:
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 9/9] dt-bindings: clock: Convert i.MX1 clock to json-schema
From: Rob Herring @ 2020-05-29 2:54 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, shc_work, sboyd, shawnguo, s.hauer, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, s.trumtrar, festevam,
mturquette, linux-arm-kernel
In-Reply-To: <1590650879-18288-10-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:59 +0800, Anson Huang wrote:
> Convert the i.MX1 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx1-clock.txt | 26 ------------
> .../devicetree/bindings/clock/imx1-clock.yaml | 49 ++++++++++++++++++++++
> 2 files changed, 49 insertions(+), 26 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: clock: Convert i.MX21 clock to json-schema
From: Rob Herring @ 2020-05-29 2:53 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, s.hauer, shc_work, sboyd, shawnguo, mturquette,
linux-kernel, robh+dt, Linux-imx, kernel, s.trumtrar, festevam,
linux-clk, linux-arm-kernel
In-Reply-To: <1590650879-18288-9-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:58 +0800, Anson Huang wrote:
> Convert the i.MX21 clock binding to DT schema format using json-schema,
> can NOT find any CCM interrupt info from reference manual and DT file,
> so interrupts property is removed from original binding doc.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx21-clock.txt | 27 ------------
> .../devicetree/bindings/clock/imx21-clock.yaml | 49 ++++++++++++++++++++++
> 2 files changed, 49 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: clock: Convert i.MX25 clock to json-schema
From: Rob Herring @ 2020-05-29 2:53 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, shc_work, sboyd, shawnguo, mturquette, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, s.trumtrar, festevam,
s.hauer, linux-arm-kernel
In-Reply-To: <1590650879-18288-8-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:57 +0800, Anson Huang wrote:
> Convert the i.MX25 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx25-clock.txt | 160 ------------------
> .../devicetree/bindings/clock/imx25-clock.yaml | 184 +++++++++++++++++++++
> 2 files changed, 184 insertions(+), 160 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: clock: Convert i.MX27 clock to json-schema
From: Rob Herring @ 2020-05-29 2:52 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, s.hauer, shc_work, sboyd, shawnguo, mturquette,
linux-kernel, robh+dt, Linux-imx, kernel, s.trumtrar, festevam,
linux-clk, linux-arm-kernel
In-Reply-To: <1590650879-18288-7-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:56 +0800, Anson Huang wrote:
> Convert the i.MX27 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx27-clock.txt | 27 -----------
> .../devicetree/bindings/clock/imx27-clock.yaml | 53 ++++++++++++++++++++++
> 2 files changed, 53 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: clock: Convert i.MX23 clock to json-schema
From: Rob Herring @ 2020-05-29 2:51 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, shc_work, sboyd, shawnguo, s.hauer, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, s.trumtrar, festevam,
mturquette, linux-arm-kernel
In-Reply-To: <1590650879-18288-6-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:55 +0800, Anson Huang wrote:
> Convert the i.MX23 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx23-clock.txt | 70 -----------------
> .../devicetree/bindings/clock/imx23-clock.yaml | 90 ++++++++++++++++++++++
> 2 files changed, 90 insertions(+), 70 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: clock: Convert i.MX28 clock to json-schema
From: Rob Herring @ 2020-05-29 2:51 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, shc_work, sboyd, festevam, mturquette, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, s.trumtrar, shawnguo,
s.hauer, linux-arm-kernel
In-Reply-To: <1590650879-18288-5-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:54 +0800, Anson Huang wrote:
> Convert the i.MX28 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx28-clock.txt | 93 -----------------
> .../devicetree/bindings/clock/imx28-clock.yaml | 113 +++++++++++++++++++++
> 2 files changed, 113 insertions(+), 93 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx28-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx28-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: clock: Convert i.MX31 clock to json-schema
From: Rob Herring @ 2020-05-29 2:48 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, shc_work, sboyd, festevam, s.hauer, linux-kernel,
mturquette, robh+dt, Linux-imx, kernel, s.trumtrar, shawnguo,
linux-clk, linux-arm-kernel
In-Reply-To: <1590650879-18288-4-git-send-email-Anson.Huang@nxp.com>
On Thu, 28 May 2020 15:27:53 +0800, Anson Huang wrote:
> Convert the i.MX31 clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx31-clock.txt | 90 ----------------
> .../devicetree/bindings/clock/imx31-clock.yaml | 118 +++++++++++++++++++++
> 2 files changed, 118 insertions(+), 90 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx31-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx31-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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