* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-09-20 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474356608.4030.7.camel@pengutronix.de>
Hi Philipp,
2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Hi Masahiro,
>
> Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> Philipp,
>>
>> IIRC, you mentioned that you were planning to consolidate the double
>> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>>
>> I have not seen it in the ML, so I am sending this.
>>
>> Please let me know if you have some updates.
>
> I had started to doodle a bit, see
>
> git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
>
> but I haven't found time for cleanup and testing.
OK, I will merge this patch for now.
BTW, I did not understand some of your commits under way.
commit 7fe911f9c83737449565db03bebf953d3d94bbbf
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date: Tue Aug 9 11:18:51 2016 +0200
dmaengine: sunx6i: do not depend on reset controller framework
The reset controller framework provides inline function stubs if
disabled.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
As far as I see from drivers/dma/sun6i-dma.c,
the reset control is mandatory for this driver.
Why are you removing the dependency?
Don't you care if it works on run-time
as long as it can build?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: AKASHI Takahiro @ 2016-09-20 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb9cf2c6-83b4-1c71-d497-67f751de9b35@windriver.com>
Jason,
On Mon, Sep 19, 2016 at 05:29:36PM -0500, Jason Wessel wrote:
> On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> >@@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
> >>> * over and over again.
> >>> */
> >>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
> >>>- atomic_set(&kgdb_cpu_doing_single_step, -1);
> >>>- kgdb_single_step = 0;
> >>
> >>This is a subtle change, but I assume it is what you intended? All the CPUs will get released into the run state when exiting the kgdb exception handler.
> >You are talking about "- kgdb_single_step = 0." Right?
>
>
> Correct.
>
> >Do you think that there is any (negative) side effect of this change?
>
>
> Not at all. The kernel debugger always skids to a stop, and it is more reliable from a locking perspective if the other CPU threads are released while a single CPU is asked to single step until the next "skid" for all the other CPUs.
>
> When you do not release the other CPUs you can end up single stepping a CPU which dead locks or never exits a lock elsewhere due to what ever it was blocking on never getting freed from another CPU.
Thank you for the explanation. This convinces me very much.
-Takahiro AKASHI
> Cheers,
> Jason.
^ permalink raw reply
* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Noralf Trønnes @ 2016-09-20 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c47a0a10-4e0b-9025-8d38-af299d5f55da@martin.sperl.org>
Den 20.09.2016 09:19, skrev Martin Sperl:
> Hi Noralf!
>
> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>> Some SMBus protocols use Repeated Start Condition to switch from write
>> mode to read mode. Devices like MMA8451 won't work without it.
>>
>> When downstream implemented support for this in i2c-bcm2708, it broke
>> support for some devices, so a module parameter was added and combined
>> transfer was disabled by default.
>> See https://github.com/raspberrypi/linux/issues/599
>> It doesn't seem to have been any investigation into what the problem
>> really was. Later there was added a timeout on the polling loop.
>>
>> One of the devices mentioned to partially stop working was DS1307.
>>
>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>> and AT24C32 (eeprom) in parallel without problems.
>>
>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>> ---
>> drivers/i2c/busses/i2c-bcm2835.c | 107
>> +++++++++++++++++++++++++++++++++++----
>> 1 file changed, 98 insertions(+), 9 deletions(-)
> ...
>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>> *adap, struct i2c_msg msgs[],
>> int i;
>> int ret = 0;
>> + /* Combined write-read to the same address (smbus) */
>> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>> + (msgs[0].len <= 16)) {
>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>> +
>> + return ret ? ret : 2;
>> + }
>> +
>> for (i = 0; i < num; i++) {
>> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>> if (ret)
>> break;
>> }
> This does not seem to implement the i2c_msg api correctly.
>
> As per comments in include/uapi/linux/i2c.h on line 58 only the last
> message
> in a group should - by default - send a STOP.
>
Apparently it's a known problem that the i2c controller doesn't support
Repeated Start. It will always issue a Stop when it has transferred DLEN
bytes.
Refs:
http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
and before DONE is set (or the last byte is shifted, I don't know excatly).
Refs:
https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
I found this answer/report by joan that the downstream combined support
isn't reliable:
http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
My implementation differs from downstream in that I use local_irq_save()
to protect the polling loop. But that only protects from missing the TA
(downstream can miss the TA and issue a Stop).
So currently in mainline we have a driver that says it support the standard
(I2C_FUNC_I2C), but it really only supports one message transfers since it
can't do ReStart.
What I have done in this patch is to support ReStart for transfers with
2 messages: first write, then read. But maybe a better solution is to just
leave this alone if it is flaky and use bitbanging instead. I don't know.
Noralf.
> As far as I understand you would need to implement the I2C_M_STOP flag
> (by exposing I2C_FUNC_PROTOCOL_MANGLING in bcm2835_i2c_func)
> to make this work correctly:
>
> for (i = 0; i < num; i++) {
> + bool send_stop = (i == num - 1) ||msgs[i]
> <http://lxr.free-electrons.com/ident?i=msg>->flags
> <http://lxr.free-electrons.com/ident?i=flags> &I2C_M_STOP
> <http://lxr.free-electrons.com/ident?i=I2C_M_STOP>;
> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], send_stop);
> if (ret)
> break;
> }
>
> The corresponding device driver (or userspace) will need to set the
> flag correctly.
>
> Martin
^ permalink raw reply
* [RFC] Arm64 boot fail with numa enable in BIOS
From: Will Deacon @ 2016-09-20 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd53a1ae-e4ff-933c-4d1c-1ddaaa999a43@huawei.com>
Hi Yisheng,
On Tue, Sep 20, 2016 at 11:29:24AM +0800, Yisheng Xie wrote:
> On 2016/9/19 22:07, Mark Rutland wrote:
> > On Mon, Sep 19, 2016 at 09:05:26PM +0800, Yisheng Xie wrote:
> > Can you modify the warning in cpumask.h to dump the bad CPU number? That
> > would make it fairly clear if that's the case.
> >
> hi Mark,
> I dump the bad CPU number, it is 64,
> And the cpumask get from task is 00000000,00000000.
>
> [ 3.873044] select_task_rq: allowed 0, allow_cpumask 00000000,00000000
> [ 3.879727] cpumask_check: cpu 64, nr_cpumask_bits:64, nr_cpu_ids= 64
> [ 3.895989] ------------[ cut here ]------------
> [ 3.900652] WARNING: CPU: 16 PID: 103 at ./include/linux/cpumask.h:122 try_to_wake_up+0x410/0x4ac
Can you look at this patch from David, please:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/458110.html
and offer a Tested-by if it fixes your problem?
Thanks,
Will
^ permalink raw reply
* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Peter Griffin @ 2016-09-20 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACvgo52_g7anGBd9HTUyYsbp5QmQEk9LR3nNHgSTgjQ29G3ViA@mail.gmail.com>
Hi Emil,
On Tue, 20 Sep 2016, Emil Velikov wrote:
> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.
> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.
I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.
For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.
For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'
git grep "select VIRTIO" | wc -l
14
git grep "depends on VIRTIO" | wc -l
10
> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.
Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).
It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.
>
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
>
I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.
I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?
regards,
Peter.
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Nava kishore Manne @ 2016-09-20 8:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Nava kishore Manne <nava.manne@xilinx.com>
This patch adds zynq specific check for bank 0 pins 7 and 8
are special and cannot be used as inputs
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index e72794e..eae9d24 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -96,6 +96,10 @@
/* GPIO upper 16 bit mask */
#define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
+/* For GPIO quirks */
+#define ZYNQ_GPIO BIT(0)
+#define ZYNQMP_GPIO BIT(1)
+
/**
* struct zynq_gpio - gpio device private data structure
* @chip: instance of the gpio_chip
@@ -122,6 +126,7 @@ struct zynq_gpio {
*/
struct zynq_platform_data {
const char *label;
+ u32 quirks;
u16 ngpio;
int max_bank;
int bank_min[ZYNQMP_GPIO_MAX_BANK];
@@ -238,13 +243,19 @@ static void zynq_gpio_set_value(struct gpio_chip *chip, unsigned int pin,
static int zynq_gpio_dir_in(struct gpio_chip *chip, unsigned int pin)
{
u32 reg;
+ bool is_zynq_gpio;
unsigned int bank_num, bank_pin_num;
struct zynq_gpio *gpio = gpiochip_get_data(chip);
+ is_zynq_gpio = gpio->p_data->quirks & ZYNQ_GPIO;
zynq_gpio_get_bank_pin(pin, &bank_num, &bank_pin_num, gpio);
- /* bank 0 pins 7 and 8 are special and cannot be used as inputs */
- if (bank_num == 0 && (bank_pin_num == 7 || bank_pin_num == 8))
+ /*
+ * On zynq bank 0 pins 7 and 8 are special and cannot be used
+ * as inputs.
+ */
+ if (is_zynq_gpio && bank_num == 0 &&
+ (bank_pin_num == 7 || bank_pin_num == 8))
return -EINVAL;
/* clear the bit in direction mode reg to set the pin as input */
@@ -609,6 +620,7 @@ static const struct dev_pm_ops zynq_gpio_dev_pm_ops = {
static const struct zynq_platform_data zynqmp_gpio_def = {
.label = "zynqmp_gpio",
+ .quirks = ZYNQMP_GPIO,
.ngpio = ZYNQMP_GPIO_NR_GPIOS,
.max_bank = ZYNQMP_GPIO_MAX_BANK,
.bank_min[0] = ZYNQ_GPIO_BANK0_PIN_MIN(MP),
@@ -627,6 +639,7 @@ static const struct zynq_platform_data zynqmp_gpio_def = {
static const struct zynq_platform_data zynq_gpio_def = {
.label = "zynq_gpio",
+ .quirks = ZYNQ_GPIO,
.ngpio = ZYNQ_GPIO_NR_GPIOS,
.max_bank = ZYNQ_GPIO_MAX_BANK,
.bank_min[0] = ZYNQ_GPIO_BANK0_PIN_MIN(),
--
2.1.2
^ permalink raw reply related
* [PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static
From: Andrzej Hajda @ 2016-09-20 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207110-16111-1-git-send-email-baoyou.xie@linaro.org>
On 18.09.2016 15:58, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
^ permalink raw reply
* [PATCH v26 6/7] arm64: kdump: update a kernel doc
From: AKASHI Takahiro @ 2016-09-20 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC18FC.9000807@arm.com>
On Fri, Sep 16, 2016 at 05:08:28PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 07/09/16 05:29, AKASHI Takahiro wrote:
> > This patch adds arch specific descriptions about kdump usage on arm64
> > to kdump.txt.
>
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>
> > @@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm)
> >
> > AUTO_ZRELADDR=y
> >
> > +Dump-capture kernel config options (Arch Dependent, arm64)
> > +----------------------------------------------------------
> > +
> > +- Please note that kvm of the dump-capture kernel will not be enabled
> > + on non-VHE systems even if it is configured. This is because the CPU
> > + cannot be reset to EL2 on panic.
>
> Nit:
> cannot be -> will not be
OK.
> We could try to do this, but its more code that could prevent us reaching the
> kdump kernel, so we choose not to.
>
>
> > @@ -370,6 +381,9 @@ For s390x:
> > For arm:
> > "1 maxcpus=1 reset_devices"
> >
> > +For arm64:
> > + "1 maxcpus=1 reset_devices"
> > +
>
> 'maxcpus=1' is a bit fragile. Since 44dbcc93ab67145 ("arm64: Fix behavior of
> maxcpus=N") udev on ubuntu vivid (running on Juno) has taken it upon itself to
> bring the secondary cores online, even when booted with 'maxcpus=1'.
>
> Can we change the recomendation to "1 nosmp reset_devices"?
Well, I have no strong opinion here, but I'm not quite sure whether
this change does make any difference in practice.
Looking at kernel/smp.c, the only difference is setup_max_cpus. But
given that arch_disable_smp_support() is null and smp_cpus_done()
ignores "max_cpus" on arm64, I don't think that the change is very
meaningful.
I might miss something.
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Marc Zyngier @ 2016-09-20 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919231441.GA60928@google.com>
On 20/09/16 00:14, Brian Norris wrote:
> On Fri, Sep 16, 2016 at 09:06:55AM +0100, Marc Zyngier wrote:
>> Hi Brian,
>
> Hi Marc,
>
> Thanks for the quick response.
>
>> On 16/09/16 06:49, Brian Norris wrote:
>>> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
>>> for suspend timekeeping"), this driver assumes that the ARM architected
>>> timer keeps running in suspend. This is not the case for some ARM SoCs,
>>> depending on the HW state used for system suspend. Let's not assume that
>>> all SoCs support this, and instead only support this if the device tree
>>> explicitly tells us it's "always on". In all other cases, just fall back
>>> to the RTC. This should be relatively harmless.
>>
>> I'm afraid you're confusing two things:
>> - the counter, which *must* carry on counting no matter what, as
>> (quoting the ARM ARM) "The system counter must be implemented in an
>> always-on power domain"
>> - the timer, which is allowed to be powered off, and can be tagged with
>> the "always-on" property to indicate that it is guaranteed to stay up
>> (which in practice only exists in virtual machines and never on real HW).
>
> Indeed, sorry for that confusion, and thanks for the explanations.
>
>> If your counter does stop counting when suspended, then this is starting
>> to either feel like a HW bug, or someone is killing the clock that feeds
>> this counter when entering suspend.
>>
>> If this is the former, then we need a separate quirk to indicate the
>> non-standard behaviour. If it is the latter, don't do it! ;-)
>
> It's beginning to seem more like a HW quirk which yields nonstandard
> behavior. AIUI, this SoC normally runs the counter off its 24 MHz clock,
> but for low power modes, this "always-on" domain switches over to a 32
> KHz alternative clock. Unfortunately, the counter doesn't actually tick
> when run this way. I'm trying to confirm with the chip designers
> (Rockchip, RK3399) about the nature of the quirk, but I think we'll need
> a separate DT flag for this behavior.
The counter is allowed to be clocked at a different rate, as long as it
is incremented by the frequency ratio on each tick of the new frequency.
In your case, the counter should increment by 750 on each tick of the
32kHz clock. If the rk3399 implementation doesn't do this, then this is
a bug, and we need a quirk to work around it.
Note that such a quirk will have some other impacts, such as the
gettimeofday implementation in the VDSO (which relies on the counter
making forward progress). There could be other issues in the timer
subsystem as well... This doesn't look like a pleasant thing to fix.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v26 3/7] arm64: kdump: add kdump support
From: AKASHI Takahiro @ 2016-09-20 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC06B0.8030504@arm.com>
On Fri, Sep 16, 2016 at 03:50:24PM +0100, James Morse wrote:
> On 07/09/16 05:29, AKASHI Takahiro wrote:
> > On crash dump kernel, all the information about primary kernel's system
> > memory (core image) is available in elf core header.
> > The primary kernel will set aside this header with reserve_elfcorehdr()
> > at boot time and inform crash dump kernel of its location via a new
> > device-tree property, "linux,elfcorehdr".
> >
> > Please note that all other architectures use traditional "elfcorehdr="
> > kernel parameter for this purpose.
> >
> > Then crash dump kernel will access the primary kernel's memory with
> > copy_oldmem_page(), which reads one page by ioremap'ing it since it does
> > not reside in linear mapping on crash dump kernel.
> >
> > We also need our own elfcorehdr_read() here since the header is placed
> > within crash dump kernel's usable memory.
>
> One nit below, looks good.
Fixed.
Thanks,
-Takahiro AKASHI
> Reviewed-by: James Morse <james.morse@arm.com>
>
>
> Thanks,
>
> James
>
>
> > diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
>
> > +/**
> > + * copy_oldmem_page() - copy one page from old kernel memory
> > + * @pfn: page frame number to be copied
> > + * @buf: buffer where the copied page is placed
> > + * @csize: number of bytes to copy
> > + * @offset: offset in bytes into the page
> > + * @userbuf: if set, @buf is in a user address space
> > + *
> > + * This function copies one page from old kernel memory into buffer pointed by
> > + * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
> > + * copied or negative error in case of failure.
> > + */
> > +ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> > + size_t csize, unsigned long offset,
> > + int userbuf)
> > +{
> > + void *vaddr;
> > +
> > + if (!csize)
> > + return 0;
> > +
> > + vaddr = memremap(__pfn_to_phys(pfn), PAGE_SIZE, MEMREMAP_WB);
> > + if (!vaddr)
> > + return -ENOMEM;
> > +
> > + if (userbuf) {
>
> > + if (copy_to_user(buf, vaddr + offset, csize)) {
>
> If you re-cast buf with (char __user *), it should stop sparse complaining:
> > ../arch/arm64/kernel/crash_dump.c:45:34: warning: incorrect type in argument 1
> (different address spaces)
> > ../arch/arm64/kernel/crash_dump.c:45:34: expected void [noderef] <asn:1>*to
> > ../arch/arm64/kernel/crash_dump.c:45:34: got char *buf
>
>
^ permalink raw reply
* [PATCH v26 2/7] arm64: kdump: implement machine_crash_shutdown()
From: AKASHI Takahiro @ 2016-09-20 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC067B.3050003@arm.com>
On Fri, Sep 16, 2016 at 03:49:31PM +0100, James Morse wrote:
> On 16/09/16 04:21, AKASHI Takahiro wrote:
> > On Wed, Sep 14, 2016 at 07:09:33PM +0100, James Morse wrote:
> >> On 07/09/16 05:29, AKASHI Takahiro wrote:
> >>> Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus
> >>> and save registers' status in per-cpu ELF notes before starting crash
> >>> dump kernel. See kernel_kexec().
> >>> Even if not all secondary cpus have shut down, we do kdump anyway.
> >>>
> >>> As we don't have to make non-boot(crashed) cpus offline (to preserve
> >>> correct status of cpus at crash dump) before shutting down, this patch
> >>> also adds a variant of smp_send_stop().
>
> >>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> >>> index 04744dc..a908958 100644
> >>> --- a/arch/arm64/include/asm/kexec.h
> >>> +++ b/arch/arm64/include/asm/kexec.h
> >>> @@ -40,7 +40,46 @@
> >>> static inline void crash_setup_regs(struct pt_regs *newregs,
> >>> struct pt_regs *oldregs)
> >>> {
> >>> - /* Empty routine needed to avoid build errors. */
> >>> + if (oldregs) {
> >>> + memcpy(newregs, oldregs, sizeof(*newregs));
> >>> + } else {
> >>> + u64 tmp1, tmp2;
> >>> +
> >>> + __asm__ __volatile__ (
> >>> + "stp x0, x1, [%2, #16 * 0]\n"
> >>> + "stp x2, x3, [%2, #16 * 1]\n"
> >>> + "stp x4, x5, [%2, #16 * 2]\n"
> >>> + "stp x6, x7, [%2, #16 * 3]\n"
> >>> + "stp x8, x9, [%2, #16 * 4]\n"
> >>> + "stp x10, x11, [%2, #16 * 5]\n"
> >>> + "stp x12, x13, [%2, #16 * 6]\n"
> >>> + "stp x14, x15, [%2, #16 * 7]\n"
> >>> + "stp x16, x17, [%2, #16 * 8]\n"
> >>> + "stp x18, x19, [%2, #16 * 9]\n"
> >>> + "stp x20, x21, [%2, #16 * 10]\n"
> >>> + "stp x22, x23, [%2, #16 * 11]\n"
> >>> + "stp x24, x25, [%2, #16 * 12]\n"
> >>> + "stp x26, x27, [%2, #16 * 13]\n"
> >>> + "stp x28, x29, [%2, #16 * 14]\n"
> >>> + "mov %0, sp\n"
> >>> + "stp x30, %0, [%2, #16 * 15]\n"
> >>> +
> >>> + "/* faked current PSTATE */\n"
> >>> + "mrs %0, CurrentEL\n"
> >>> + "mrs %1, DAIF\n"
> >>> + "orr %0, %0, %1\n"
> >>> + "mrs %1, NZCV\n"
> >>> + "orr %0, %0, %1\n"
> >>> +
> >>
> >> What about SPSEL? While we don't use it, it is correctly preserved for
> >> everything except a CPU that calls panic()...
> >
> > My comment above might be confusing, but what I want to fake
> > here is "spsr" as pt_regs.pstate is normally set based on spsr_el1.
> > So there is no corresponding field of SPSEL in spsr.
>
> Here is my logic, I may have missed something obvious, see what you think:
>
> SPSR_EL{1,2} shows the CPU mode 'M' in bits 0-4, From aarch64 bit 4 is always 0.
> From the register definitions in the ARM-ARM C5.2, likely values in 0-3 are:
> 0100 EL1t
> 0101 EL1h
> 1000 EL2t
> 1001 EL2h
>
> I'm pretty sure this least significant bit is what SPSEL changes, so it does get
> implicitly recorded in SPSR.
> CurrentEL returns a value in bits 0-3, of which 0-1 are RES0, so we lose the
> difference between EL?t and EL?h.
OK.
SPSel will be added assuming that CurrentEL is never 0 here.
>
> >
> >>
> >>> + /* pc */
> >>> + "adr %1, 1f\n"
> >>> + "1:\n"
> >>> + "stp %1, %0, [%2, #16 * 16]\n"
> >>> + : "=r" (tmp1), "=r" (tmp2), "+r" (newregs)
> >>> + :
> >>> + : "memory"
>
> Do you need the memory clobber? This asm only modifies values in newregs.
What about this (including the change above):
| "/* faked current PSTATE */\n"
| "mrs %0, CurrentEL\n"
| "mrs %1, SPSEL\n"
| "orr %0, %0, %1\n"
| "mrs %1, DAIF\n"
| "orr %0, %0, %1\n"
| "mrs %1, NZCV\n"
| "orr %0, %0, %1\n"
| /* pc */
| "adr %1, 1f\n"
| "1:\n"
| "stp %1, %0, [%2, #16 * 16]\n"
| : "+r" (tmp1), "+r" (tmp2)
| : "r" (newregs)
| : "memory"
>
> >>> + );
> >>> + }
> >>> }
> >>>
> >>> #endif /* __ASSEMBLY__ */
>
>
> >>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>
> >>> +#ifdef CONFIG_KEXEC_CORE
> >>> +void smp_send_crash_stop(void)
> >>> +{
> >>> + cpumask_t mask;
> >>> + unsigned long timeout;
> >>> +
> >>> + if (num_online_cpus() == 1)
> >>> + return;
> >>> +
> >>> + cpumask_copy(&mask, cpu_online_mask);
> >>> + cpumask_clear_cpu(smp_processor_id(), &mask);
> >>> +
> >>> + atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
> >>> +
> >>> + pr_crit("SMP: stopping secondary CPUs\n");
> >>> + smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
> >>> +
> >>> + /* Wait up to one second for other CPUs to stop */
> >>> + timeout = USEC_PER_SEC;
> >>> + while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
> >>> + udelay(1);
> >>> +
> >>> + if (atomic_read(&waiting_for_crash_ipi) > 0)
> >>> + pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
> >>> + cpumask_pr_args(cpu_online_mask));
> >>> +}
> >>> +#endif
> >>
> >> This is very similar to smp_send_stop() which also has the timeout. Is it
> >> possible to merge them? You could use in_crash_kexec to choose the IPI type.
> >
> > Yeah, we could merge them along with ipi_cpu_(crash_)stop().
> > But the resulting code would be quite noisy if each line
> > is switched by "if (in_crash_kexec)."
> > Otherwise, we may have one big "if" like:
> > void smp_send_stop(void)
> > {
> > if (in_crash_kexec)
> > ...
> > else
> > ...
> > }
> > It seems to me that it is not much different from the current code.
> > What do you think?
>
> Hmm, yes, its too fiddly to keep the existing behaviour of both.
>
> The problems are ipi_cpu_stop() doesn't call cpu_die(), (I can't see a good
> reason for this, but more archaeology is needed), and ipi_cpu_crash_stop()
> doesn't modify the online cpu mask.
>
> I don't suggest we do this yet, but it could be future cleanup if it's proved to
> be safe:
> smp_send_stop() is only called from: machine_halt(), machine_power_off(),
> machine_restart() and panic(). In all those cases the CPUs are never expected to
> come back, so we can probably merge the IPIs. This involves modifying the
> online cpu mask during kdump, (which I think is fine as it uses the atomic
> bitops so we won't get blocked on a lock), and promoting in_crash_kexec to some
> atomic type.
>
> But I think we should leave it as it is for now,
Sure.
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Philipp Zabel @ 2016-09-20 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474346599-29925-1-git-send-email-yamada.masahiro@socionext.com>
Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Philipp Zabel @ 2016-09-20 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474346599-29925-1-git-send-email-yamada.masahiro@socionext.com>
Hi Masahiro,
Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Philipp,
>
> IIRC, you mentioned that you were planning to consolidate the double
> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>
> I have not seen it in the ML, so I am sending this.
>
> Please let me know if you have some updates.
I had started to doodle a bit, see
git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
but I haven't found time for cleanup and testing.
regards
Philipp
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Gregory CLEMENT @ 2016-09-20 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4288010.vBvIiUCvY8@wuerfel>
Hi Arnd,
On lun., sept. 19 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, September 19, 2016 11:46:22 PM CEST Arnd Bergmann wrote:
>> On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
>> > mvebu soc for 4.9 (part 1)
>> >
>> > - irq cleanup for old mvebu SoC
>> > - Convert orion5x based SoC Netgear WNR854T to devicetree
>> >
>>
>> Pulled into next/soc, thanks!
>
> Sorry, backed out again after seeing the PCI stuff on the WNR854T in
> there. I thought the plan was to leave out PCI support from the DT
> based machine file, and leave the old board in place, or am I
> missing something?
I might have overlooked the thread, I thouhgt the state of the patch was
OK as is, and further changes can be done later.
So it seems that it will be 4.10 material.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] pci/layercape: disable all iATUs before initialization
From: M.H. Lian @ 2016-09-20 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914211053.GD13189@localhost>
Hi Bjorn,
Thanks for your reply.
Please see my comments inline.
Best Regards,
Minghuan
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Thursday, September 15, 2016 5:11 AM
> To: M.H. Lian <minghuan.lian@nxp.com>
> Cc: linux-pci at vger.kernel.org; Roy Zang <roy.zang@nxp.com>; Arnd
> Bergmann <arnd@arndb.de>; Jingoo Han <jg1.han@samsung.com>; Stuart
> Yoder <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; linux-arm-
> kernel at lists.infradead.org; Bjorn Helgaas <bhelgaas@google.com>; Mingkai
> Hu <mingkai.hu@nxp.com>
> Subject: Re: [PATCH 1/2] pci/layercape: disable all iATUs before initialization
>
> On Thu, Sep 08, 2016 at 02:25:49PM +0800, Minghuan Lian wrote:
> > Layerscape PCIe has 6 outbound iATUs. The bootloader such as u-boot
> > uses 4 iATUs for CFG0 CFG1 IO and MEM separately. But Designware
> > driver only uses two outbound iATUs. To avoid conflict between enabled
> > but unused iATUs with used iATUs under Linux and unexpected behavior,
> > the patch disables all iATUs before initialization.
>
> Do we need similar changes in other DesignWare-based drivers?
[Minghuan Lian] Yes. I think so.
I could provide a patch for all the Designware-based drivers.
Could you give me suggestion how to get ATU number of all kinds of PCIe controller?
1. Add optional "num-atu" property to designware-based PCIe dts node?
2. The specific driver assign a variable "num-atu" before calling dw_pcie_host_init()
We could achieve benefits if the ATU number is bigger than two (current default value)
1. A dedicated ATU is for IO map. It will avoid conflict IO and config access simultaneously.
2. Supports multiple ATUs for prefetchable and non-prefetchable memory and the memory size can be greater than 4G.
>
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > drivers/pci/host/pci-layerscape.c | 17 +++++++++++++++--
> > drivers/pci/host/pcie-designware.c | 7 +++++++
> > drivers/pci/host/pcie-designware.h | 1 +
> > 3 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-layerscape.c
> > b/drivers/pci/host/pci-layerscape.c
> > index 114ba81..cf783ad 100644
> > --- a/drivers/pci/host/pci-layerscape.c
> > +++ b/drivers/pci/host/pci-layerscape.c
> > @@ -38,6 +38,8 @@
> > /* PEX LUT registers */
> > #define PCIE_LUT_DBG 0x7FC /* PEX LUT Debug Register */
> >
> > +#define PCIE_IATU_NUM 6
> > +
> > struct ls_pcie_drvdata {
> > u32 lut_offset;
> > u32 ltssm_shift;
> > @@ -55,6 +57,8 @@ struct ls_pcie {
> >
> > #define to_ls_pcie(x) container_of(x, struct ls_pcie, pp)
> >
> > +static void ls_pcie_host_init(struct pcie_port *pp);
>
> I would prefer to reorder the function definitions so the forward declaration
> is not necessary. This would be two patches:
>
> 1) Reorder functions (no functional change)
> 2) Disable iATUs
[Minghuan Lian] ok. I will change it.
>
> > static bool ls_pcie_is_bridge(struct ls_pcie *pcie) {
> > u32 header_type;
> > @@ -87,6 +91,14 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
> > iowrite32(val, pcie->dbi + PCIE_STRFMR1); }
> >
> > +static void ls_pcie_disable_outbound_atus(struct ls_pcie *pcie) {
> > + int i;
> > +
> > + for (i = 0; i < PCIE_IATU_NUM; i++)
> > + dw_pcie_disable_outbound_atu(&pcie->pp, i);
>
> It looks like maybe the DesignWare ATUs are generic enough that we could
> move the loop into the generic code, e.g.,
>
> void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int count)
> {
> int i;
>
> for (i = 0; i < count; i++) {
> dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | i,
> PCIE_ATU_VIEWPORT);
> dw_pcie_writel_rc(pp, 0, PCIE_ATU_CR2);
> }
> }
>
[Minghuan Lian] Yes. And, If we add "num-atu" property to dts node.
Designware driver can directly clear ATUs and the specific driver needs to do nothing.
> > +
> > static int ls1021_pcie_link_up(struct pcie_port *pp) {
> > u32 state;
> > @@ -124,9 +136,8 @@ static void ls1021_pcie_host_init(struct pcie_port
> *pp)
> > }
> > pcie->index = index[1];
> >
> > + ls_pcie_host_init(pp);
> > dw_pcie_setup_rc(pp);
> > -
> > - ls_pcie_drop_msg_tlp(pcie);
>
> Can you split this to a separate patch? This hunk changes
> ls1021_pcie_host_init() so it does several things in addition to
> ls_pcie_drop_msg_tlp(), and it is unrelated to the "disable iATU" change.
[Minghuan Lian] OK. I will change it.
>
> > }
> >
> > static int ls_pcie_link_up(struct pcie_port *pp) @@ -153,6 +164,8 @@
> > static void ls_pcie_host_init(struct pcie_port *pp)
> > ls_pcie_clear_multifunction(pcie);
> > ls_pcie_drop_msg_tlp(pcie);
> > iowrite32(0, pcie->dbi + PCIE_DBI_RO_WR_EN);
> > +
> > + ls_pcie_disable_outbound_atus(pcie);
> > }
> >
> > static int ls_pcie_msi_host_init(struct pcie_port *pp, diff --git
> > a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c
> > index 12afce1..e4d1203 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -172,6 +172,13 @@ static void dw_pcie_prog_outbound_atu(struct
> pcie_port *pp, int index,
> > dw_pcie_readl_rc(pp, PCIE_ATU_CR2, &val); }
> >
> > +void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int index) {
> > + dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
> > + PCIE_ATU_VIEWPORT);
> > + dw_pcie_writel_rc(pp, 0, PCIE_ATU_CR2); }
> > +
> > static struct irq_chip dw_msi_irq_chip = {
> > .name = "PCI-MSI",
> > .irq_enable = pci_msi_unmask_irq,
> > diff --git a/drivers/pci/host/pcie-designware.h
> > b/drivers/pci/host/pcie-designware.h
> > index f437f9b..e998bfc 100644
> > --- a/drivers/pci/host/pcie-designware.h
> > +++ b/drivers/pci/host/pcie-designware.h
> > @@ -85,5 +85,6 @@ int dw_pcie_wait_for_link(struct pcie_port *pp);
> > int dw_pcie_link_up(struct pcie_port *pp); void
> > dw_pcie_setup_rc(struct pcie_port *pp); int dw_pcie_host_init(struct
> > pcie_port *pp);
> > +void dw_pcie_disable_outbound_atu(struct pcie_port *pp, int index);
> >
> > #endif /* _PCIE_DESIGNWARE_H */
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
From: Tomasz Nowicki @ 2016-09-20 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919180900.GB13775@localhost>
On 19.09.2016 20:09, Bjorn Helgaas wrote:
> On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
>> thunder-pem driver stands for being ACPI based PCI host controller.
>> However, there is no standard way to describe its PEM-specific register
>> ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension
>> to obtain hardcoded addresses from static resource array.
>> Although it is not pretty, it prevents from creating standard mechanism to
>> handle similar cases in future.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++--------
>> 1 file changed, 48 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
>> index 6abaf80..b048761 100644
>> --- a/drivers/pci/host/pci-thunder-pem.c
>> +++ b/drivers/pci/host/pci-thunder-pem.c
>> @@ -18,6 +18,7 @@
>> #include <linux/init.h>
>> #include <linux/of_address.h>
>> #include <linux/of_pci.h>
>> +#include <linux/pci-acpi.h>
>> #include <linux/pci-ecam.h>
>> #include <linux/platform_device.h>
>>
>> @@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>> return pci_generic_config_write(bus, devfn, where, size, val);
>> }
>>
>> +#ifdef CONFIG_ACPI
>> +static struct resource thunder_pem_reg_res[] = {
>> + [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M),
>> + [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M),
>> + [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M),
>> + [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M),
>> + [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M),
>> + [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M),
>> + [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M),
>> + [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M),
>> + [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M),
>> + [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M),
>> + [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M),
>> + [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M),
>
> 1) The "correct" way to discover the resources consumed by an ACPI
> device is to use the _CRS method. I know there are some issues
> there for bridges (not the fault of ThunderX!) because there's not
> a good way to distinguish windows from resources consumed directly
> by the bridge.
>
> But we should either do this correctly, or include a comment about
> why we're doing it wrong, so we don't give the impression that this
> is the right way to do it.
>
> I seem to recall some discussion about why we're doing it this way,
> but I don't remember the details. It'd be nice to include a
> summary here.
OK I will. The reason why we cannot use _CRS for this case is that
CONSUMER flag was not use consistently for the bridge so far.
>
> 2) This is a little weird because here we define the resource size as
> 16MB, in the OF case we get the resource size from OF, in either
> case we ioremap 64K of it, and then as far as I can tell, we only
> ever access PEM_CFG_WR and PEM_CFG_RD, at offsets 0x28 and 0x30
> into the space.
>
> If the hardware actually decodes the entire 16MB, we should ioremap
> the whole 16MB. (Strictly speaking, drivers only need to ioremap
> the parts they're using, but in this case nobody claims the entire
> resource because of deficiencies in the ACPI and OF cores, so the
> driver should ioremap the entire thing to help prevent conflicts
> with other devices.)
>
> It'd be nice if we didn't have the 64KB magic number. I think
> using devm_ioremap_resource() would be nice.
I agree.
David, is there anything which prevents us from using
devm_ioremap_resource() here with SZ_16M size?
Tomasz
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: aspeed: Enable BT IPMI BMC device
From: Joel Stanley @ 2016-09-20 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-4-git-send-email-clg@kaod.org>
On Tue, Sep 20, 2016 at 4:31 PM, C?dric Le Goater <clg@kaod.org> wrote:
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
Acked-by: Joel Stanley <joel@jms.id.au>
I'll put this in my tree to send to Arnd.
Cheers,
Joel
> ---
>
> Changes since v1:
>
> - added the soc name ast2400 in the compatible cell
>
> arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
> arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 22dee5937d5c..7bb00b6f13d8 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -82,6 +82,12 @@
> clocks = <&clk_apb>;
> };
>
> + ibt: ibt at 1e789140 {
> + compatible = "aspeed,ast2400-bt-bmc";
> + reg = <0x1e789140 0x18>;
> + interrupts = <8>;
> + };
> +
> wdt1: wdt at 1e785000 {
> compatible = "aspeed,wdt";
> reg = <0x1e785000 0x1c>;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index dd94d9361fda..1d8f81b548b3 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -86,6 +86,12 @@
> clocks = <&clk_apb>;
> };
>
> + ibt: ibt at 1e789140 {
> + compatible = "aspeed,ast2400-bt-bmc";
> + reg = <0x1e789140 0x18>;
> + interrupts = <8>;
> + };
> +
> wdt1: wdt at 1e785000 {
> compatible = "aspeed,wdt";
> reg = <0x1e785000 0x1c>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 2/3] ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
From: Joel Stanley @ 2016-09-20 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-3-git-send-email-clg@kaod.org>
On Tue, Sep 20, 2016 at 4:31 PM, C?dric Le Goater <clg@kaod.org> wrote:
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
Acked-by: Joel Stanley <joel@jms.id.au>
I'll this in my tree to send to Arnd.
Cheers,
Joel
> ---
>
> Changes since v1:
>
> - renamed config option
>
> arch/arm/configs/aspeed_g4_defconfig | 1 +
> arch/arm/configs/aspeed_g5_defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
> index ca39c04fec6b..af3847db00f8 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -53,6 +53,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_SHARE_IRQ=y
> CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_ASPEED_BT_IPMI_BMC=y
> # CONFIG_HW_RANDOM is not set
> # CONFIG_USB_SUPPORT is not set
> # CONFIG_IOMMU_SUPPORT is not set
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index 4f366b0370e9..5d46290736fb 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -54,6 +54,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_SHARE_IRQ=y
> CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_ASPEED_BT_IPMI_BMC=y
> # CONFIG_HW_RANDOM is not set
> # CONFIG_USB_SUPPORT is not set
> # CONFIG_IOMMU_SUPPORT is not set
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate
From: Maxime Ripard @ 2016-09-20 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65Lj2YSwGv=VtrT1NC+guXwMvh7J3c36_vk+5c1vAXhcg@mail.gmail.com>
On Mon, Sep 19, 2016 at 11:36:18PM +0800, Chen-Yu Tsai wrote:
> On Mon, Sep 19, 2016 at 3:16 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote:
> >> With display pixel clocks we want to have the closest possible clock
> >> rate, to minimize timing and refresh rate skews. Whether the actual
> >> clock rate is higher or lower than the requested rate is less important.
> >>
> >> Also check candidates against the requested rate, rather than the
> >> ideal parent rate, the varying dividers also influence the difference
> >> between the requested rate and the rounded rate.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> drivers/gpu/drm/sun4i/sun4i_dotclock.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> index 3eb99784f371..d401156490f3 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> @@ -90,7 +90,8 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
> >> goto out;
> >> }
> >>
> >> - if ((rounded < ideal) && (rounded > best_parent)) {
> >> + if (abs(rate - rounded / i) <
> >> + abs(rate - best_parent / best_div)) {
> >
> > I'm not sure what you're trying to do here. Why is the divider involved?
>
> Say you want the dotclock at X, so you try Y = 6 ~ 127 for the divider.
> Now you're asking the CCF to round (X*Y).
>
> In the original code, you were comparing the result of rounding (X * Y).
>
> if ((rounded < ideal) && (rounded > best_parent)) {
> best_parent = rounded;
> best_div = i;
> }
>
> where ideal = X * Y (i in the code). Given the divider increases in
> the loop, you are actually not closing in on the best divider, but the
> highest divider that doesn't give a higher rate than the ideal rate.
>
> Including the divider makes it compare the actual dot clock frequency
> if a given divider was used.
>
> Does this makes sense? Explaining this kind of makes my head spin...
Yes, sorry, I didn't remember rounded was actually the rounded parent
rate.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/40c61675/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate
From: Maxime Ripard @ 2016-09-20 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915151402.15992-5-wens@csie.org>
On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote:
> With display pixel clocks we want to have the closest possible clock
> rate, to minimize timing and refresh rate skews. Whether the actual
> clock rate is higher or lower than the requested rate is less important.
>
> Also check candidates against the requested rate, rather than the
> ideal parent rate, the varying dividers also influence the difference
> between the requested rate and the rounded rate.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160920/81bddca7/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Martin Sperl @ 2016-09-20 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474298777-5858-2-git-send-email-noralf@tronnes.org>
Hi Noralf!
On 19.09.2016 17:26, Noralf Tr?nnes wrote:
> Some SMBus protocols use Repeated Start Condition to switch from write
> mode to read mode. Devices like MMA8451 won't work without it.
>
> When downstream implemented support for this in i2c-bcm2708, it broke
> support for some devices, so a module parameter was added and combined
> transfer was disabled by default.
> See https://github.com/raspberrypi/linux/issues/599
> It doesn't seem to have been any investigation into what the problem
> really was. Later there was added a timeout on the polling loop.
>
> One of the devices mentioned to partially stop working was DS1307.
>
> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
> and AT24C32 (eeprom) in parallel without problems.
>
> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
> ---
> drivers/i2c/busses/i2c-bcm2835.c | 107 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 98 insertions(+), 9 deletions(-)
...
> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
> int i;
> int ret = 0;
>
> + /* Combined write-read to the same address (smbus) */
> + if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
> + !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
> + (msgs[0].len <= 16)) {
> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
> +
> + return ret ? ret : 2;
> + }
> +
> for (i = 0; i < num; i++) {
> - ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
> + ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
> if (ret)
> break;
> }
This does not seem to implement the i2c_msg api correctly.
As per comments in include/uapi/linux/i2c.h on line 58 only the last message
in a group should - by default - send a STOP.
As far as I understand you would need to implement the I2C_M_STOP flag
(by exposing I2C_FUNC_PROTOCOL_MANGLING in bcm2835_i2c_func)
to make this work correctly:
for (i = 0; i < num; i++) {
+ bool send_stop = (i == num - 1) ||msgs[i] <http://lxr.free-electrons.com/ident?i=msg>->flags <http://lxr.free-electrons.com/ident?i=flags> &I2C_M_STOP <http://lxr.free-electrons.com/ident?i=I2C_M_STOP>;
- ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
+ ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], send_stop);
if (ret)
break;
}
The corresponding device driver (or userspace) will need to set the flag
correctly.
Martin
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Gregory CLEMENT @ 2016-09-20 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4134529.ol6KhRYAQp@wuerfel>
Hi Arnd,
On mar., sept. 20 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, September 14, 2016 5:35:10 PM CEST Gregory CLEMENT wrote:
>> mvebu drivers for 4.9 (part 1)
>>
>> - Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
>>
>> ----------------------------------------------------------------
>> Jamie Lentin (2):
>> clk: mvebu: Add clk support for the orion5x SoC mv88f5181
>> pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
>>
>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
>> .../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
>> drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
>> drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
>> 4 files changed, 86 insertions(+), 12 deletions(-)
>
> I see this touches pinctrl and clk drivers, but none of the maintainers are
> on Cc for this pull request, nor have they provided an Ack for the patches
> according to your git log.
>
> Why did you not send the driver changes to them?
My bad sorry. The changes only touch data (adding new varaiant of the
orion5x), are very trivial and won't cause any merge
conflict. Furthermore there is depency with the other pacthes in the
mvebu branches and we already did this in the past to avoid dependecy
between subsystem. _But_ I should have asked the acked-by from the
drivers maintainers, it was the way we wolved it in the past and I
forgot it.
>
> Not pulled for now, until this is resolved, sorry.
If the drivers maintainer for pinctrl and clk give their acked-by do you
agree to take it for 4.9?
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Tomasz Nowicki @ 2016-09-20 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919154550.GA13775@localhost>
On 19.09.2016 17:45, Bjorn Helgaas wrote:
> On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
>> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
>> compliant with ECAM standard. It uses non-standard configuration space
>> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
>> (see bus_shift = 24). In order to access configuration space and
>> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
>> infrastructure. This involves:
>> 1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>> code.
>> 2. New quirk entries for each PEM segment. Each contains platform IDs,
>> mentioned pci_thunder_pem_ops and CFG resources.
>>
>> Quirk is considered for ThunderX silicon pass2.x only which is identified
>> via MCFG revision 1.
>
> Is it really the case that silicon pass2.x has MCFG revision 1, and
> silicon pass1.x has MCFG revision 2? That just seems backwards.
It is weird but silicon pass2.x is more common and it had MCFG revision
1 from the beginning. Unless it is allowed to use MCFG revision 0 ? Then
we could use MCFG revision 0 for pass1.x
Tomasz
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: aspeed: Enable BT IPMI BMC device
From: Cédric Le Goater @ 2016-09-20 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-1-git-send-email-clg@kaod.org>
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
Changes since v1:
- added the soc name ast2400 in the compatible cell
arch/arm/boot/dts/aspeed-g4.dtsi | 6 ++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 22dee5937d5c..7bb00b6f13d8 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -82,6 +82,12 @@
clocks = <&clk_apb>;
};
+ ibt: ibt at 1e789140 {
+ compatible = "aspeed,ast2400-bt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ };
+
wdt1: wdt at 1e785000 {
compatible = "aspeed,wdt";
reg = <0x1e785000 0x1c>;
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index dd94d9361fda..1d8f81b548b3 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -86,6 +86,12 @@
clocks = <&clk_apb>;
};
+ ibt: ibt at 1e789140 {
+ compatible = "aspeed,ast2400-bt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ };
+
wdt1: wdt at 1e785000 {
compatible = "aspeed,wdt";
reg = <0x1e785000 0x1c>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] ARM: aspeed: Add defconfigs for CONFIG_ASPEED_BT_IPMI_BMC
From: Cédric Le Goater @ 2016-09-20 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-1-git-send-email-clg@kaod.org>
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
Changes since v1:
- renamed config option
arch/arm/configs/aspeed_g4_defconfig | 1 +
arch/arm/configs/aspeed_g5_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig
index ca39c04fec6b..af3847db00f8 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -53,6 +53,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ASPEED_BT_IPMI_BMC=y
# CONFIG_HW_RANDOM is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
index 4f366b0370e9..5d46290736fb 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -54,6 +54,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=6
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ASPEED_BT_IPMI_BMC=y
# CONFIG_HW_RANDOM is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_IOMMU_SUPPORT is not set
--
2.7.4
^ permalink raw reply related
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