* [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
From: H. Nikolaus Schaller @ 2018-01-12 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112153903.GB5992@localhost>
Hi Johan,
> Am 12.01.2018 um 16:39 schrieb Johan Hovold <johan@kernel.org>:
>
>> Let's restart this discussion and focus on the main roadblock (others
>> are minor details which can be sorted out later).
>>
>> If it feels like a hack, the key issue seems to me to be the choice of
>> the API to present the GPS data to user space. Right?
>
> Or even more fundamentally, does this belong in the kernel at all?
Yes, that can be questioned of course. It was questioned and discussed
several times and I thought the answer was a clear yes. But let's reiterate.
>
> Also it seems at least part of your specific problem is that you have
> failed to wire up the WAKEUP pin of the W2SG0004/84 properly,
The w2sg0004 has no wakeup pin. At least I can't find one in the data sheet.
The two pins you refer to from the 0084 data sheet are called BootSelect0/1
in the 0004 and have a different function.
To be clear, we did not fail to wire it up. We did the design before the
0084 was announced and available. We just had to swap in the 0084 into
existing PCBs during production because the 0004 became EOL. Otherwise
we would probably still use the 0004 without WAKEUP output.
To make it worse, we have no documentation for an individual board if
an 0004 or 0084 chip is installed and there is no means how a software
can find out which one it is talking to (especially before properly
powering on). Therefore we can not even provide two different device
trees or drivers or whatever, unless we ask people to open their device
and look on the chip. Quite crazy wrt. user-friendlyness of software
installation in 2018...
Therefore, a driver must be capable to handle both chips in the same way,
with minimalistic assumptions, even if the 0084 could provide a direct
signal to make it easier than using serdev to monitor the data stream.
> which then
> forces you to look at the data stream to determine the power state of
> the chip. Judging from a quick look at the GTA04 schematics it seems
> you've even connected the WAKEUP output to the 1V8_OUT output?!
No. You failed to see that this is an optional 0R, which is not installed.
The 0R on pin 7 (BootSelect1) to GND was removed when we did switch from
0004 to 0084. Pin 6 (BootSelect0/WAKEUP) was never connected.
> The kernel is probably not the place to be working around issues like
> that,
You appear to assume this our only motivation is to make a workaround for
a hardware design flaw but that isn't.
The purpose of the driver is to provide power management for the GPS
subsystem which happens to be based on a chip with limited functionality.
And the serdev thing is the solution, not the requirement...
> even if serdev at least allows for such hacks to be fairly
> isolated in drivers (unlike some of the earlier proposals touching core
> code).
Please tell me why there are so many hacks for hardware issues in certain
drivers. Any why those are good and this one (if it is one at all) is not.
Some picks random fgrep -iR hack drivers
drivers/char/random.c: * Hack to deal with crazy userspace progams when they are all trying
drivers/clk/meson/meson8b.c: * a new clk_hw, and this hack will no longer work. Releasing the ccr
drivers/clk/samsung/clk-exynos3250.c: /* HACK: fin_pll hardcoded to xusbxti until detection is implemented. */
drivers/gpu/drm/amd/amdkfd/kfd_events.c: * This hack is wrong, but nobody is likely to notice.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: * HACK: IGT tests expect that each plane can only have one
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: /* It's a hack for s3 since in 4.9 kernel filter out cursor buffer
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: /* TODO This hack should go away */
drivers/gpu/drm/amd/display/dc/core/dc_link.c: /* A hack to avoid failing any modes for EDID override feature on
What I can learn from your discussion is that it might be considerable
to add an optional gpio for the 0084 WAKEUP and add some logic to
support users who have or will have that pin connected.
But even then we would need a driver to handle this gpio and issue
an on/off impulse on the other to switch states. It would be a different
driver (variant - maybe some CONFIG option or handled by code), but not
"no driver".
>
>> I see three reasonable options how this presentation can be done:
>>
>> 1. char device
>> 2. tty device
>> 3. some new gps interface API (similar to network, bluetooth interfaces)
>> 4. no driver and use the UART tty directly
>>
>> Pros and cons:
>
>> 4. no driver and use UART directly
>> + a non-solution seems to be attractive
>> - must turn on/off chip by gpio hacks from user-space
>
> I'm not sure that would amount to more of hack then doing it in the
> kernel would.
It might not be big effort in the user-space code/scripts.
But much effort to convince all the plethora of user-space client maintainers
to integrate something. And have them roll out. And have distributions take it.
And have users upgrade to it. 5 years later...
Do you think it is easier to convince them than you? They usually assume a
power management issue should be solved by the kernel driver.
That is what Andreas did remark as motivation: provide a solution
for *existing* user spaces.
>
>> - can not guarantee (!) to power off the chip if the last user-space
>> process using it is killed (which is essential for power-management of
>> a handheld, battery operated device)
>
> That depends on how you implement things (extending gpsd, wrapper
> script, pty daemon, ...).
No. You can of course cover all standard cases but there is one fundamental
issue which is IMHO a problem of any user-space implementation:
How can you guarantee that the chip is powered off if no
user-space process is using it or if the last process doing
this is killed by *whatever* reason?
E.g. after a kill -9. Or if someone deinstalls gpsd or whatever and assumes
(and wants a guarantee) that GPS is now turned off and never turned on drawing
precious milliamps from the battery for no use.
As it is well known, a user-space process can't protect itself against kill -9.
Or has this recently been changed and I am not aware of?
This is the fundamental reason why we need a kernel driver to provide
reliable, repeatable and trustable power management of this chip.
It is equally fundamental as a hard disk should spin down after the last
file is closed. Even if this process ends by a kill -9.
A second almost equally fundamental aspect to be considered is how you want
to automatically and reliably turn off the chip by pure user-space code when
entering suspend.
>
>
>> I would clearly prefer 3 over 2 over 1 over 4.
>>
>> So do you see a chance that the kernel core team provides something useable
>> (not perfect) for variant 3 in reasonable time (let's say 3-6 months)?
>
> No, I'm afraid not. At least not if we're talking about a framework
> that would replace gpsd.
This confirms my assumption that there is nothing really good to expect
soon to implement a driver for variant 3.
>
>> If not, I want to suggest to accept the second-best choice 2. for now and we
>> will update the driver as soon as 3. appears. IMHO it would be a good test case
>> for a new subsystem.
>
> Getting the interface right from the start is quite important, as
> otherwise we may end up having to support a superseded one for a long
> time.
This seems to contradict your argument that user-space can very easily
adapt to everything. If the latter were true there would be no need to
keep old interfaces supported for a long time.
So can you agree to that a battery powered portable device must have
reliable and trustable power management? And if it provable can't be
implemented in user-space (a single counter example suffices) it must
be a kernel driver?
BR,
Nikolaus
^ permalink raw reply
* EDAC driver for ARMv8 L1/L2 cache
From: Mark Rutland @ 2018-01-12 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR04MB20780EF853A0822A6EFCFE449A170@VI1PR04MB2078.eurprd04.prod.outlook.com>
On Fri, Jan 12, 2018 at 05:44:56PM +0000, York Sun wrote:
> On 01/12/2018 09:38 AM, Mark Rutland wrote:
> > On Fri, Jan 12, 2018 at 05:17:54PM +0000, York Sun wrote:
> >> On 01/12/2018 09:13 AM, Borislav Petkov wrote:
> >>> On Fri, Jan 12, 2018 at 04:48:05PM +0000, York Sun wrote:
> >>>> I see Stratix10 has A53 core. I am concerned on reading the
> >>>> CPUMERRSR_EL1 and L2MERRSR_EL1. The are IMPLEMENTATION DEFINED
> >>>> registers. They may not be available on all SoCs, or all time.
> >>>
> >>> Is there something like CPUID on x86, on ARM64 which denotes presence of
> >>> a certain feature?
> >>>
> >>> Or is that thing devicetree?
> >>
> >> This feature is available on the SoC I am working on (NXP LS1046A). It
> >> seems always there. I don't know if there is any register denoting the
> >> existence of such feature.
> >
> > There is no architectural register describing this.
> >
> > Judging by the Cortex-A53 TRM, there is no IMP DEF / auxilliary register
> > describing this.
> >
> > Regardless, a DT binding is necessary due to potential interactions with
> > FW, hypervisors, etc.
> >
> >> I guess we can use device tree if this feature exists. Not sure if
> >> big.LITTLE is a concern here.
> >
> > There are big.LITTLE systems with Cortex-A53, so we definitely care
> > about big.LITTLE here.
> >
>
> For a given system, for example A72-A53 big.LITTLE configuration, the
> feature is known and can be described in DT. We have to detect which
> core is running to determine if this feature is available. Does this
> sound right?
The binding will need to explicitly describe the set of CPUs the feature
is usable on.
On a big.LITTLE system, I'd expect multiple nodes in the DT, similar to
what we have for PMUs. Even if all CPUs have some EDAC functionality, it
will differ across microarchitectures.
e.g. we'd have something like:
edac-a72 {
compatible = "arm,cortex-a72-edac";
cpus = <&cpu0>, <&cpu 1>;
...
};
edac-a53 {
compatible = "arm,cortex-a53-edac";
cpus = <&cpu2>, <&cpu 3>;
...
};
... and it may get more complicated from there on. There may be other
users like FW or Secure OSs that we have to interact with, this might
get arbitrarily reset across idle, etc.
The Cortex-A53 TRM doesn't use the term EDAC at all, and refers
separately to "CPU Memory Error" functionality an "L2 Memory Error"
functionality. I don't know if those are expected to be used separately.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: James Morse @ 2018-01-12 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506cd212-3d16-ba2a-518f-34982bc162fc@huawei.com>
Hi gengdongjiu,
On 15/12/17 03:30, gengdongjiu wrote:
> On 2017/12/7 14:37, gengdongjiu wrote:
>>> We need to tackle (1) and (3) separately. For (3) we need some API that lets
>>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have
>>> a way of migrating pending SError yet... which is where I got stuck last time I
>>> was looking at this.
>> I understand you most idea.
>>
>> But In the Qemu one signal type can only correspond to one behavior, can not correspond to two behaviors,
>> otherwise Qemu will do not know how to do.
>>
>> For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the CPER
>> records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if receives the SIGBUS_MCEERR_AO
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
>>
>> not involve _trigger_ an SError.
>>
>> so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
>
> As I explained above:
>
> If Qemu received SIGBUS_MCEERR_AR, it will record CPER and trigger Synchronous External Abort;
> If Qemu received SIGBUS_MCEERR_AO, it will record CPER and trigger GPIO IRQ;
> So Qemu does not know when to _trigger_ an SError.
There is no answer to this. How the CPU decides is specific to the CPU design.
How Qemu decides is going to be specific to the machine it emulates.
My understanding is there is some overlap for which RAS errors are reported as
synchronous external abort, and which use SError. (Obviously the imprecise ones
are all SError). Which one the CPU uses depends on how the CPU is designed.
When you take an SIGBUS_MCEERR_AR from KVM, its because KVM can't complete a
stage2 fault because the page is marked with PG_poisoned. These started out as a
synchronous exception, but you could still report these with SError.
We don't have a way to signal user-space about imprecise exceptions, this isn't
a KVM specific problem.
> so here I "return a error" to Qemu if ghes_notify_sei() return failure in [1], if you opposed KVM "return error",
> do you have a better idea about it? thanks
If ghes_notify_sei() fails to claim the error, we should drop through to
kernel-first-handling. We don't have that yet, just the stub that ignores errors
where we can make progress.
If neither firmware-first nor kernel-first claim a RAS error, we're in trouble.
I'd like to panic() as we got a RAS notification but no description of the
error. We can't do this until we have kernel-first support, hence that stub.
> About the way of migrating pending SError, I think it is a separate case, because Qemu still does not know
> how and when to trigger the SError.
I agree, but I think we should fix this first before we add another user of this
unmigratable hypervisor state.
(I recall someone saying migration is needed for any new KVM/cpu features, but I
can't find the thread)
> [1]:
> static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
> {
> .......................
> + case ESR_ELx_AET_UER: /* The error has not been propagated */
> + /*
> + * Userspace only handle the guest SError Interrupt(SEI) if the
> + * error has not been propagated
> + */
> + run->exit_reason = KVM_EXIT_EXCEPTION;
> + run->ex.exception = ESR_ELx_EC_SERROR;
I'm against telling user space RAS errors ever happened, only the final
user-visible error when the kernel can't fix it.
This is inventing something new for RAS errors not claimed by firmware-first.
If we have kernel-first too, this will never happen. (unless your system is
losing the error description).
Your system has firmware-first, why isn't it claiming the notification?
If its not finding CPER records written by firmware, check firmware and the UEFI
memory map agree on the attributes to be used when read/writing that area.
> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
> + return 0;
Thanks,
James
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: James Morse @ 2018-01-12 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMj-D2CwHWNpXzeNMEVKGTveAwuJvja219NF6PZ7xqYMUY17Kw@mail.gmail.com>
Hi gengdongjiu,
On 16/12/17 04:47, gengdongjiu wrote:
> [...]
>>
>>> + case ESR_ELx_AET_UER: /* The error has not been propagated */
>>> + /*
>>> + * Userspace only handle the guest SError Interrupt(SEI) if the
>>> + * error has not been propagated
>>> + */
>>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>>> + run->ex.exception = ESR_ELx_EC_SERROR;
>>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>>> + return 0;
>>
>> We should not pass RAS notifications to user space. The kernel either handles
>> them, or it panics(). User space shouldn't even know if the kernel supports RAS
>
> For the ESR_ELx_AET_UER(Recoverable error), let us see its definition
> below, which get from [0]
[..]
> so we can see the exception is precise and PE can recover execution
> from the preferred return address of the exception,
> so let guest handling it is
> better, for example, if it is guest application RAS error, we can kill
> the guest application instead of panic whole OS; if it is guest kernel
> RAS error, guest will panic.
If the kernel takes an unhandled RAS error it should panic - we don't know where
the error is.
I understand you want to kill-off guest tasks as a result of RAS errors, but
this needs to go through the whole APEI->memory_failure()->sigbus machinery so
that the kernel knows the kernel can keep running.
This saves us signalling user-space when we don't need to. An example:
code-corruption. Linux can happily re-read affected user-space executables from
disk, there is absolutely nothing user-space can do about it.
Handling errors first in the kernel allows us to do recovery for all the
affected processes, not just the one that happens to be running right now.
> Host does not know which application of guest has error, so host can
> not handle it,
It has to work this out, otherwise the errors we can handle never get a chance.
This kernel is expected to look at the error description, (which for some reason
we aren't talking about here), e.g. the CPER records, and determine what
recovery action is necessary for this error.
For memory errors this may be re-reading from disk, or at the worst case,
unmapping from all user-space users (including KVM's stage2) and raining signals
on all affected processes.
For a memory error the important piece of information is the physical address.
Only the kernel can do anything with this, it determines who owns the affected
memory and what needs doing to recover from the error.
If you pass the notification to user-space, all it can do is signal the guest to
"stop doing whatever it is you're doing". The guest may have been able to
re-read pages from disk, or otherwise handle the error.
Has the error been handled? No: The error remains latent in the system.
> panic OS is not a good choice for the Recoverable error.
If we don't know where the error is, and we can't make progress, its the only
sane choice.
This code is never expected to run! (why are we arguing about it?) We should get
RAS errors as GHES notifications from firmware via some mechanism. If those are
NOTIFY_SEI then APEI should claim the notification and kick off the appropriate
handling based on the CPER records. If/when we get kernel-first, that can claim
the SError. What we're left with is RAS notifications that no-one claimed
because there was no error-description found.
James
^ permalink raw reply
* [GIT PULL] TI DaVinci SoC updates for v4.16 (part 2)
From: Olof Johansson @ 2018-01-12 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a0bd7f2-c3a9-1322-a567-7a9ffdaf69d8@ti.com>
On Thu, Jan 11, 2018 at 9:47 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Olof,
>
> On Friday 12 January 2018 08:06 AM, David Lechner wrote:
>> On 01/11/2018 07:36 PM, Olof Johansson wrote:
>>> On Wed, Jan 10, 2018 at 04:55:05PM +0530, Sekhar Nori wrote:
>>>> The following changes since commit
>>>> 23bbeaef90ab7607d03428bbb708efe44f43c761:
>>>>
>>>> ARM: davinci: constify gpio_led (2018-01-05 19:28:41 +0530)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
>>>> tags/davinci-for-v4.16/soc-p2
>>>>
>>>> for you to fetch changes up to 0808d3260456aaba061fe06ead31d578c8bdc936:
>>>>
>>>> ARM: davinci: remove watchdog reset (2018-01-10 14:38:07 +0530)
>>>>
>>>> ----------------------------------------------------------------
>>>> A patch to shift to using watchdog timer for DaVinci restart
>>>> functionality.
>>>> The driver support is present in linux-next as 71d1f058844d "watchdog:
>>>> davinci_wdt: add restart function"
>>>
>>> Hi,
>>>
>>> So if this is merged before the driver is merged, what happens?
>>
>> Then reboot hangs.
>
> Yes. I did request[1] an immutable branch with just the driver change
> applied, but looks like the message was lost and the current driver
> change is applied over many other watchdog changes.
>
>>
>>> Might
>>> be better to hold off a release to avoid regressions?
>
> The main reason I sent it out anyway is because this cleanup is a
> dependency to move to common clock framework and I want to reduce those
> to a minimum to have a good chance of migrating to it in v4.17.
>
> If the watchdog driver change never makes it (very low chance), then I
> can resend a revert for -rc2. If ARM-SoC is merged before watchdog, yes,
> during a short while in merge window reboot will be broken. But I
> figured its a risk worth taking to have a chance of getting this into v4.16.
>
> If you have a "send these late" branch, it will be nice to put it in
> there. If this is too much uncertainty, then okay, lets hold for v4.17.
Keep in mind that while the tree might regress for a period of time,
what's really awkward is that bisection will be hard across this,
since for some states of the tree you will have the platform-side
change but not the watchdog change. That's really one of the main
reasons for having a stable branch that can be used as a base -- you
can then not hit that case.
One option is to make a base branch that contains this code that's
used for the base of the CCF work that is based on 4.16-rc1 once it is
out. What trees to do you expect to have CCF code going through? Clock
and arm-soc, any others? If it's just those two we can deal with that,
if it's more trees than that it might get complicated still.
-Olof
^ permalink raw reply
* EDAC driver for ARMv8 L1/L2 cache
From: York Sun @ 2018-01-12 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112180048.srniseo2ft7ytqve@lakrids.cambridge.arm.com>
On 01/12/2018 10:01 AM, Mark Rutland wrote:
> On Fri, Jan 12, 2018 at 05:44:56PM +0000, York Sun wrote:
>> On 01/12/2018 09:38 AM, Mark Rutland wrote:
>>> On Fri, Jan 12, 2018 at 05:17:54PM +0000, York Sun wrote:
>>>> On 01/12/2018 09:13 AM, Borislav Petkov wrote:
>>>>> On Fri, Jan 12, 2018 at 04:48:05PM +0000, York Sun wrote:
>>>>>> I see Stratix10 has A53 core. I am concerned on reading the
>>>>>> CPUMERRSR_EL1 and L2MERRSR_EL1. The are IMPLEMENTATION DEFINED
>>>>>> registers. They may not be available on all SoCs, or all time.
>>>>>
>>>>> Is there something like CPUID on x86, on ARM64 which denotes presence of
>>>>> a certain feature?
>>>>>
>>>>> Or is that thing devicetree?
>>>>
>>>> This feature is available on the SoC I am working on (NXP LS1046A). It
>>>> seems always there. I don't know if there is any register denoting the
>>>> existence of such feature.
>>>
>>> There is no architectural register describing this.
>>>
>>> Judging by the Cortex-A53 TRM, there is no IMP DEF / auxilliary register
>>> describing this.
>>>
>>> Regardless, a DT binding is necessary due to potential interactions with
>>> FW, hypervisors, etc.
>>>
>>>> I guess we can use device tree if this feature exists. Not sure if
>>>> big.LITTLE is a concern here.
>>>
>>> There are big.LITTLE systems with Cortex-A53, so we definitely care
>>> about big.LITTLE here.
>>>
>>
>> For a given system, for example A72-A53 big.LITTLE configuration, the
>> feature is known and can be described in DT. We have to detect which
>> core is running to determine if this feature is available. Does this
>> sound right?
>
> The binding will need to explicitly describe the set of CPUs the feature
> is usable on.
>
> On a big.LITTLE system, I'd expect multiple nodes in the DT, similar to
> what we have for PMUs. Even if all CPUs have some EDAC functionality, it
> will differ across microarchitectures.
>
> e.g. we'd have something like:
>
> edac-a72 {
> compatible = "arm,cortex-a72-edac";
> cpus = <&cpu0>, <&cpu 1>;
> ...
> };
>
> edac-a53 {
> compatible = "arm,cortex-a53-edac";
> cpus = <&cpu2>, <&cpu 3>;
> ...
> };
>
> ... and it may get more complicated from there on. There may be other
> users like FW or Secure OSs that we have to interact with, this might
> get arbitrarily reset across idle, etc.
>
> The Cortex-A53 TRM doesn't use the term EDAC at all, and refers
> separately to "CPU Memory Error" functionality an "L2 Memory Error"
> functionality. I don't know if those are expected to be used separately.
>
Mark,
Thanks a lot for the guidance. I now have a better idea to deal with
big.LITTLE systems.
Can you explain more about the IMPLEMENTATION DEFINED registers? I
consulted our design team and was told there isn't a build parameter to
opt in or out these registers. So they are always available in our SoCs.
Under what condition these IMPLEMENTATION DEFINED registers would not be
available?
York
^ permalink raw reply
* [GIT PULL] ARM64: Xilinx ZynqMP SoC patches for v4.16
From: Olof Johansson @ 2018-01-12 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0JwAW2ZhQAQ6A3o9KC9sXe7qRJT7ZM+rZxGXX9dk0ADg@mail.gmail.com>
On Fri, Jan 12, 2018 at 12:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jan 12, 2018 at 7:44 AM, Michal Simek <monstr@monstr.eu> wrote:
>> On 12.1.2018 02:28, Olof Johansson wrote:
>>> On Mon, Jan 08, 2018 at 02:02:18PM +0100, Michal Simek wrote:
>
>>>> ----------------------------------------------------------------
>>>> Dhaval Shah (2):
>>>> dt-bindings: soc: xilinx: Add DT bindings to xlnx_vcu driver
>>>> soc: xilinx: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver
>>>>
>>>> Michal Simek (1):
>>>> soc: xilinx: Create folder structure for soc specific drivers
>>>>
>>>
>>> Merged, but you should probably add a platform config option for Xilinx
>>> and use that instead of obj-y to descend into the directory?
>
> I don't see it in arm-soc yet, did you forget to push the latest branches?
Hm, not sure what happened there. Fixing now.
>
>> Do you think change like this?
>>
>> -obj-y += xilinx/
>> +obj-$(CONFIG_ARCH_ZYNQMP) += xilinx/
>>
>> Just a note. This folder is supposed to be used by arm64/arm32 and
>> microblaze that's why I didn't put there any single config because it
>> doesn't exist. If you suggest to introduce new config option to label
>> xilinx platforms we can talk about it.
>> Argument against it could be also using these drivers by openrisc or
>> mips (mipsfpga) which are also fpga based.
>> Anyway I am happy to hear what you suggest.
>>
>
> I think obj-y is fine in this case, the cost is minimal.
Yeah, if it's across platforms/architectures like this it's fine.
-Olof
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Olof Johansson @ 2018-01-12 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <419d5b97-9d8e-dcbe-3984-006f1e261161@arm.com>
On Fri, Jan 12, 2018 at 7:27 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 12/01/18 12:58, Thierry Reding wrote:
>> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>>
>>>
>>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>
>>>>> After moving the SoC device initialization to an early initcall in
>>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>>> for the device is enabled in the kernel configuration.
>>>>>
>>>>> This causes an additional SoC device to appear on platforms that already
>>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>>> causes various scripts and programs to fail because they don't know how
>>>>> to parse that data.
>>>>>
>>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>>> that already prevents the code from doing anything nonsensical on non-
>>>>> STB platforms.
>>>>>
>>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>> ---
>>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>>> static int __init brcmstb_soc_device_init(void)
>>>>> {
>>>>> struct soc_device_attribute *soc_dev_attr;
>>>>> + struct device_node *sun_top_ctrl;
>>>>> struct soc_device *soc_dev;
>>>>>
>>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>>> + if (!sun_top_ctrl)
>>>>> + return -ENODEV;
>>>>> +
>>>>
>>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>>
>>>
>>> Further, I still the error messags on my Juno with this patch applied. I
>>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>>
>> I'm not sure I understand. There's no way we can prevent the early
>> initcall from running. The point here is to prevent it from running code
>> that shouldn't be run on a platform.
>>
>
> Sorry for missing the context, I was referring [1]
>
> --
> Regards,
> Sudeep
>
> [1] [1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
Do we have an incremental patch coming, or should I revert this?
-Olof
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Miquel Raynal @ 2018-01-12 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111222833.GA15584@1wt.eu>
Hello Willy,
On Thu, 11 Jan 2018 23:28:33 +0100
Willy Tarreau <w@1wt.eu> wrote:
> Hi Miquel,
>
> On Tue, Jan 09, 2018 at 11:36:30AM +0100, Miquel Raynal wrote:
> > These changes have been tested on:
> > - PXA3xx platform with a CM-X300 board (2kiB page NAND, 1b/512B
> > strength, Hamming ECC engine) [32 bits]
> > - Armada 385 DB AP (4kiB page NAND, 4b/512B, BCH ECC engine) [32
> > bits]
> > - Armada 398 DB (4kiB page NAND, 8b/512B, BCH ECC engine using a
> > layout with a last chunk different than the others) [32 bits]
> > - Armada 7040 DB and Armada 8040 DB (4kiB page NAND, 4b/512B,
> > BCH ECC engine) [64 bits]
> > - Triax dvb-tc board (2kiB page NAND, 4b/512B, BCH ECC engine)
> > [32 bits]
>
> If you're interested, I have a mirabox with an armada 370 which uses
> the same driver. I've not powered it up for a while but if that can
> be useful I can try to find some time for this.
Thank you very much for the proposal!
For the moment I don't think there is a need as this type of platform
has already been tested, but I keep it in mind.
Thanks again!
Miqu?l
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Olof Johansson @ 2018-01-12 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgtUcWhn+PqCnCKBmSm-tihP31GmfFHO7+hL9HWkwk2JQ@mail.gmail.com>
On Fri, Jan 12, 2018 at 10:19 AM, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Jan 12, 2018 at 7:27 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 12/01/18 12:58, Thierry Reding wrote:
>>> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>
>>>>>> After moving the SoC device initialization to an early initcall in
>>>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>>>> for the device is enabled in the kernel configuration.
>>>>>>
>>>>>> This causes an additional SoC device to appear on platforms that already
>>>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>>>> causes various scripts and programs to fail because they don't know how
>>>>>> to parse that data.
>>>>>>
>>>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>>>> that already prevents the code from doing anything nonsensical on non-
>>>>>> STB platforms.
>>>>>>
>>>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>>> ---
>>>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>>>> 1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>>>> static int __init brcmstb_soc_device_init(void)
>>>>>> {
>>>>>> struct soc_device_attribute *soc_dev_attr;
>>>>>> + struct device_node *sun_top_ctrl;
>>>>>> struct soc_device *soc_dev;
>>>>>>
>>>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>>>> + if (!sun_top_ctrl)
>>>>>> + return -ENODEV;
>>>>>> +
>>>>>
>>>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>>>
>>>>
>>>> Further, I still the error messags on my Juno with this patch applied. I
>>>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>>>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>>>
>>> I'm not sure I understand. There's no way we can prevent the early
>>> initcall from running. The point here is to prevent it from running code
>>> that shouldn't be run on a platform.
>>>
>>
>> Sorry for missing the context, I was referring [1]
>>
>> --
>> Regards,
>> Sudeep
>>
>> [1] [1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
>
>
> Do we have an incremental patch coming, or should I revert this?
Oh, d'oh. Just noticed the 3-patch series.
Acks from the involved parties would be appreciated before I apply.
-Olof
^ permalink raw reply
* [PATCH 1/3] arm: spear600: Add missing interrupt-parent of rtc
From: Olof Johansson @ 2018-01-12 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2SO4=YKBE3L_AKsyfNe77YR7a8F=dvbS=ic03=6NK8MA@mail.gmail.com>
On Fri, Jan 12, 2018 at 12:56 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>> On 11-01-18, 18:07, Olof Johansson wrote:
>>>> On Thu, Jan 11, 2018 at 11:28:51AM +0530, Viresh Kumar wrote:
>>>> > The interrupt-parent of rtc was missing, add it.
>>>> >
>>>> > Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes")
>>>> > Cc: stable at vger.kernel.org # v3.8+
>>>> > Reported-by: Arnd Bergmann <arnd@arndb.de>
>>>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>>>
>>>> Applied to next/dt. Is stable really needed on this? It's been broken since
>>>> pretty much forever, and nobody has complained... :)
>>>
>>> Not sure. Just thought it may be useful for someone somewhere :)
>>
>> Ok. Left the tags there, but didn't merge into fixes since we're late
>> in -rc and this didn't seem critical at this time.
>
> My plan was to have these in the fixes branch in the hope of making
> it to a clean build for 4.15 after all, they fix warnings that got introduced
> by the updated dtc checks in 4.15-rc1.
>
> We are getting fairly close, but it seems we still miss a few, so we
> might as well give up at this point. The remaining fixes should be easy
> to backport into v4.15.y if we decide to do it, of further back even.
> For v4.14 and before, the in-kernel copy of dtc won't warn, but mainline
> dtc will.
>
> Greg, let me know your thoughts on this for the upcoming 4.15.y
> release. We had hundreds of dtc warnings in 4.15-rc1, many of them
> about important bugs, now we're down to a couple of warnings
> for platforms we don't care about much, and I expect the last of
> these fixes to land in 4.16-rc1 or maybe -rc2. Shall we backport
> them all to get a clean 4.15.y release?
I think it makes more sense to disable the warnings than to backport a
bunch of warning fixes this late. The code is working, has worked for
a long time it's just that Rob enabled the warnings by default. We can
keep them enabled for 4.16.
Rob?
> Note: there was at least one dtc warning fix that caused a serious
> regression in code that relied on a device probe to fail because of
> an invalid node (a fix is still in the works for 4.15), though generally
> the fixes are really harmless and can only make things better.
Exactly why picking up warning fixes this late is probably not a great idea.
-Olof
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Florian Fainelli @ 2018-01-12 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgdoVMy_3fGuZOZUeS5yaF=0is6wGKmKP1FB=Zk8tHskQ@mail.gmail.com>
On 01/12/2018 10:21 AM, Olof Johansson wrote:
> On Fri, Jan 12, 2018 at 10:19 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Jan 12, 2018 at 7:27 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>>
>>> On 12/01/18 12:58, Thierry Reding wrote:
>>>> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>>
>>>>>>> After moving the SoC device initialization to an early initcall in
>>>>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>>>>> for the device is enabled in the kernel configuration.
>>>>>>>
>>>>>>> This causes an additional SoC device to appear on platforms that already
>>>>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>>>>> causes various scripts and programs to fail because they don't know how
>>>>>>> to parse that data.
>>>>>>>
>>>>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>>>>> that already prevents the code from doing anything nonsensical on non-
>>>>>>> STB platforms.
>>>>>>>
>>>>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>>>> ---
>>>>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>>>>> 1 file changed, 5 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>>>>> static int __init brcmstb_soc_device_init(void)
>>>>>>> {
>>>>>>> struct soc_device_attribute *soc_dev_attr;
>>>>>>> + struct device_node *sun_top_ctrl;
>>>>>>> struct soc_device *soc_dev;
>>>>>>>
>>>>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>>>>> + if (!sun_top_ctrl)
>>>>>>> + return -ENODEV;
>>>>>>> +
>>>>>>
>>>>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>>>>
>>>>>
>>>>> Further, I still the error messags on my Juno with this patch applied. I
>>>>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>>>>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>>>>
>>>> I'm not sure I understand. There's no way we can prevent the early
>>>> initcall from running. The point here is to prevent it from running code
>>>> that shouldn't be run on a platform.
>>>>
>>>
>>> Sorry for missing the context, I was referring [1]
>>>
>>> --
>>> Regards,
>>> Sudeep
>>>
>>> [1] [1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
>>
>>
>> Do we have an incremental patch coming, or should I revert this?
>
> Oh, d'oh. Just noticed the 3-patch series.
>
> Acks from the involved parties would be appreciated before I apply.
Please revert, I will submit a simpler fix which is a combination of
Thierry's and Sudeep's patches. Sorry about the mess.
--
Florian
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Olof Johansson @ 2018-01-12 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c805425-40fd-68d2-65c7-4f3c25f315a6@gmail.com>
On Fri, Jan 12, 2018 at 10:27 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 01/12/2018 10:21 AM, Olof Johansson wrote:
>> On Fri, Jan 12, 2018 at 10:19 AM, Olof Johansson <olof@lixom.net> wrote:
>>> On Fri, Jan 12, 2018 at 7:27 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>
>>>>
>>>> On 12/01/18 12:58, Thierry Reding wrote:
>>>>> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>>>>
>>>>>>>> After moving the SoC device initialization to an early initcall in
>>>>>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>>>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>>>>>> for the device is enabled in the kernel configuration.
>>>>>>>>
>>>>>>>> This causes an additional SoC device to appear on platforms that already
>>>>>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>>>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>>>>>> causes various scripts and programs to fail because they don't know how
>>>>>>>> to parse that data.
>>>>>>>>
>>>>>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>>>>>> that already prevents the code from doing anything nonsensical on non-
>>>>>>>> STB platforms.
>>>>>>>>
>>>>>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>>>>> ---
>>>>>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>>>>>> 1 file changed, 5 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>>>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>>>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>>>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>>>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>>>>>> static int __init brcmstb_soc_device_init(void)
>>>>>>>> {
>>>>>>>> struct soc_device_attribute *soc_dev_attr;
>>>>>>>> + struct device_node *sun_top_ctrl;
>>>>>>>> struct soc_device *soc_dev;
>>>>>>>>
>>>>>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>>>>>> + if (!sun_top_ctrl)
>>>>>>>> + return -ENODEV;
>>>>>>>> +
>>>>>>>
>>>>>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>>>>>
>>>>>>
>>>>>> Further, I still the error messags on my Juno with this patch applied. I
>>>>>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>>>>>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>>>>>
>>>>> I'm not sure I understand. There's no way we can prevent the early
>>>>> initcall from running. The point here is to prevent it from running code
>>>>> that shouldn't be run on a platform.
>>>>>
>>>>
>>>> Sorry for missing the context, I was referring [1]
>>>>
>>>> --
>>>> Regards,
>>>> Sudeep
>>>>
>>>> [1] [1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
>>>
>>>
>>> Do we have an incremental patch coming, or should I revert this?
>>
>> Oh, d'oh. Just noticed the 3-patch series.
>>
>> Acks from the involved parties would be appreciated before I apply.
>
> Please revert, I will submit a simpler fix which is a combination of
> Thierry's and Sudeep's patches. Sorry about the mess.
Done.
-Olof
^ permalink raw reply
* [PATCH v2 03/16] pwm: cros-ec: update documentation regarding pwm-cells
From: Brian Norris @ 2018-01-12 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515766983-15151-4-git-send-email-claudiu.beznea@microchip.com>
On Fri, Jan 12, 2018 at 04:22:50PM +0200, Claudiu Beznea wrote:
> pwm-cells should be at least 2 to provide channel number and period value.
Nacked-by: Brian Norris <briannorris@chromium.org>
We don't control the period from the kernel; only the duty cycle. (Now,
that's perhaps not a wise firmware interface, and we may fix that
someday, but you can't just declare a breaking change to a documented,
reviewed binding.)
> Cc: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
> Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
> index 472bd46ab5a4..03347fd302b5 100644
> --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
> @@ -8,7 +8,7 @@ Documentation/devicetree/bindings/mfd/cros-ec.txt).
>
> Required properties:
> - compatible: Must contain "google,cros-ec-pwm"
> -- #pwm-cells: Should be 1. The cell specifies the PWM index.
> +- #pwm-cells: Should be 2. The cell specifies the PWM index.
Umm, "2 cells", but you use the singular "cell", and don't document what
the second one is? That's nonsense.
Brian
>
> Example:
> cros-ec at 0 {
> @@ -18,6 +18,6 @@ Example:
>
> cros_ec_pwm: ec-pwm {
> compatible = "google,cros-ec-pwm";
> - #pwm-cells = <1>;
> + #pwm-cells = <2>;
> };
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3] rcutorture: Add basic ARM64 support to run scripts
From: Lihao Liang @ 2018-01-12 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112175203.GX9671@linux.vnet.ibm.com>
On 2018/1/13 1:52, Paul E. McKenney wrote:
> On Fri, Jan 12, 2018 at 06:11:32PM +0800, lianglihao at huawei.com wrote:
>> From: Lihao Liang <lianglihao@huawei.com>
>>
>> This commit adds support of the qemu command qemu-system-aarch64
>> to rcutorture.
>>
>> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
>
> This is to replace your previous patch, not to apply on top of it,
> correct? (Either way is fine, just please let me know.)
>
Please replace the previous one.
Thanks,
Lihao.
> Thanx, Paul
>
>> ---
>>
>> Comparing to the previous version, this patch lifts the limitation of
>> maximum 8 CPUs of option "-M virt" by adding "gic-version=host" to it.
>> This allows qemu to use the maximum CPU number supported by the actual
>> hardware.
>>
>> This commit is against RCU's git branch rcu/dev
>>
>> commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
>>
>>
>> tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
>> index 07a1377..65f6655 100644
>> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
>> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
>> @@ -136,6 +136,9 @@ identify_boot_image () {
>> qemu-system-x86_64|qemu-system-i386)
>> echo arch/x86/boot/bzImage
>> ;;
>> + qemu-system-aarch64)
>> + echo arch/arm64/boot/Image
>> + ;;
>> *)
>> echo vmlinux
>> ;;
>> @@ -158,6 +161,9 @@ identify_qemu () {
>> elif echo $u | grep -q "Intel 80386"
>> then
>> echo qemu-system-i386
>> + elif echo $u | grep -q aarch64
>> + then
>> + echo qemu-system-aarch64
>> elif uname -a | grep -q ppc64
>> then
>> echo qemu-system-ppc64
>> @@ -176,16 +182,20 @@ identify_qemu () {
>> # Output arguments for the qemu "-append" string based on CPU type
>> # and the TORTURE_QEMU_INTERACTIVE environment variable.
>> identify_qemu_append () {
>> + local console=ttyS0
>> case "$1" in
>> qemu-system-x86_64|qemu-system-i386)
>> echo noapic selinux=0 initcall_debug debug
>> ;;
>> + qemu-system-aarch64)
>> + console=ttyAMA0
>> + ;;
>> esac
>> if test -n "$TORTURE_QEMU_INTERACTIVE"
>> then
>> echo root=/dev/sda
>> else
>> - echo console=ttyS0
>> + echo console=$console
>> fi
>> }
>>
>> @@ -197,6 +207,9 @@ identify_qemu_args () {
>> case "$1" in
>> qemu-system-x86_64|qemu-system-i386)
>> ;;
>> + qemu-system-aarch64)
>> + echo -machine virt,gic-version=host -cpu host
>> + ;;
>> qemu-system-ppc64)
>> echo -enable-kvm -M pseries -nodefaults
>> echo -device spapr-vscsi
>> @@ -254,7 +267,7 @@ specify_qemu_cpus () {
>> echo $2
>> else
>> case "$1" in
>> - qemu-system-x86_64|qemu-system-i386)
>> + qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
>> echo $2 -smp $3
>> ;;
>> qemu-system-ppc64)
>> --
>> 2.7.4
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Florian Fainelli @ 2018-01-12 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <973b2445-48ca-87a9-b4c2-21d8bfec76dd@arm.com>
On 01/12/2018 04:12 AM, Sudeep Holla wrote:
>
>
> On 12/01/18 11:39, Sudeep Holla wrote:
>>
>>
>> On 09/01/18 14:54, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> After moving the SoC device initialization to an early initcall in
>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>> the Broadcom STB SoC device is registered on all platforms if support
>>> for the device is enabled in the kernel configuration.
>>>
>>> This causes an additional SoC device to appear on platforms that already
>>> register a native one. In case of Tegra the STB SoC device is registered
>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>> causes various scripts and programs to fail because they don't know how
>>> to parse that data.
>>>
>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>> that already prevents the code from doing anything nonsensical on non-
>>> STB platforms.
>>>
>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>> ---
>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>> static int __init brcmstb_soc_device_init(void)
>>> {
>>> struct soc_device_attribute *soc_dev_attr;
>>> + struct device_node *sun_top_ctrl;
>>> struct soc_device *soc_dev;
>>>
>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>> + if (!sun_top_ctrl)
>>> + return -ENODEV;
>>> +
>>
>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>
>
> Further, I still the error messags on my Juno with this patch applied. I
> fail to see how this patch prevents brcmstb_biuctrl_init which is
> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
I read your patch too quickly, yours is needed, and so is Thierry's, I
will send an incremental fix to Olof shortly, sorry about the mess.
--
Florian
^ permalink raw reply
* [PATCH v2 01/16] drivers: pwm: core: use a single of xlate function
From: Brian Norris @ 2018-01-12 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515766983-15151-2-git-send-email-claudiu.beznea@microchip.com>
Hi,
On Fri, Jan 12, 2018 at 04:22:48PM +0200, Claudiu Beznea wrote:
> Remove of_pwm_simple_xlate() and of_pwm_xlate_with_flags() functions
> and add of_pwm_xlate() which is used in all cases no mather if the OF
> bindings are with PWM flags or not. This should not affect the old
> behavior since the xlate will be based on #pwm-cells property of the
> PWM controller. Based on #pwm-cells property the xlate will consider
> the flags or not. This will permit the addition of other inputs to OF
> xlate by just adding proper code at the end of of_pwm_xlate() and a new
> input to enum pwm_args_xlate_options. With this changes there will be
> no need to fill of_xlate and of_pwm_n_cells of struct pwm_chip from
> the drivers probe methods. References in drives to references to of_xlate
> and of_pwm_n_cells were removed. Drivers which used private of_xlate
> functions switched to the generic of_pwm_xlate() function which fits
> for it but with little changes in device trees (these drivers translated
> differently the "pwms" bindings; the "pwms" bindings now are generic to
> all drivers and all drivers should provide them in the format described
> in pwm documentation).
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Mike Dunn <mikedunn@newsguy.com>
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
>
> This patch (and the next 7) could be applied independetly by this series, if
> any, but I choosed to have it here since it makes easy the PWM modes parsing.
> If you feel it could be independently of this series I could send a new version.
>
> Also, Thierry, Mike, Brian, Shiyan, please take an extra look over pwm-pxa.c,
> pwm-cros-ec.c and pwm-clps711x.c since these were moved to use the generic
> pwms (minimum 2 pwm-cells).
>
> drivers/pwm/core.c | 56 +++++++++++-------------------------------
> drivers/pwm/pwm-atmel-hlcdc.c | 2 --
> drivers/pwm/pwm-atmel-tcb.c | 2 --
> drivers/pwm/pwm-atmel.c | 6 -----
> drivers/pwm/pwm-bcm-iproc.c | 2 --
> drivers/pwm/pwm-bcm-kona.c | 2 --
> drivers/pwm/pwm-bcm2835.c | 2 --
> drivers/pwm/pwm-berlin.c | 2 --
> drivers/pwm/pwm-clps711x.c | 11 ---------
> drivers/pwm/pwm-cros-ec.c | 20 ---------------
For pwm-cros-ec.c:
Nacked-by: Brian Norris <briannorris@chromium.org>
This is a fiat change of the documented binding, which breaks the RK3399
Kevin board. That's not how we do device tree.
You can extend the binding if you want, so you can represent the period
in the device tree if you'd like (though the value won't mean anything;
it can't be changed by the kernel), but don't break existing device
trees.
> drivers/pwm/pwm-fsl-ftm.c | 2 --
> drivers/pwm/pwm-hibvt.c | 2 --
> drivers/pwm/pwm-imx.c | 8 ------
> drivers/pwm/pwm-lpc18xx-sct.c | 2 --
> drivers/pwm/pwm-meson.c | 2 --
> drivers/pwm/pwm-omap-dmtimer.c | 2 --
> drivers/pwm/pwm-pxa.c | 19 --------------
> drivers/pwm/pwm-renesas-tpu.c | 2 --
> drivers/pwm/pwm-rockchip.c | 5 ----
> drivers/pwm/pwm-samsung.c | 3 ---
> drivers/pwm/pwm-sun4i.c | 2 --
> drivers/pwm/pwm-tiecap.c | 2 --
> drivers/pwm/pwm-tiehrpwm.c | 2 --
> drivers/pwm/pwm-vt8500.c | 2 --
> drivers/pwm/pwm-zx.c | 2 --
> include/linux/pwm.h | 23 ++++++++++-------
> 26 files changed, 29 insertions(+), 156 deletions(-)
>
...
> diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
> index 9c13694eaa24..692298693768 100644
> --- a/drivers/pwm/pwm-cros-ec.c
> +++ b/drivers/pwm/pwm-cros-ec.c
> @@ -133,24 +133,6 @@ static void cros_ec_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> state->duty_cycle = ret;
> }
>
> -static struct pwm_device *
> -cros_ec_pwm_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
> -{
> - struct pwm_device *pwm;
> -
> - if (args->args[0] >= pc->npwm)
> - return ERR_PTR(-EINVAL);
> -
> - pwm = pwm_request_from_chip(pc, args->args[0], NULL);
> - if (IS_ERR(pwm))
> - return pwm;
> -
> - /* The EC won't let us change the period */
> - pwm->args.period = EC_PWM_MAX_DUTY;
> -
> - return pwm;
> -}
> -
> static const struct pwm_ops cros_ec_pwm_ops = {
> .get_state = cros_ec_pwm_get_state,
> .apply = cros_ec_pwm_apply,
> @@ -207,8 +189,6 @@ static int cros_ec_pwm_probe(struct platform_device *pdev)
> /* PWM chip */
> chip->dev = dev;
> chip->ops = &cros_ec_pwm_ops;
> - chip->of_xlate = cros_ec_pwm_xlate;
> - chip->of_pwm_n_cells = 1;
> chip->base = -1;
> ret = cros_ec_num_pwms(ec);
> if (ret < 0) {
...
Brian
^ permalink raw reply
* [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
From: Andreas Kemnade @ 2018-01-12 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112144647.GA5992@localhost>
On Fri, 12 Jan 2018 15:46:47 +0100
Johan Hovold <johan@kernel.org> wrote:
> On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote:
> > On Fri, 22 Dec 2017 13:44:27 +0100
> > Johan Hovold <johan@kernel.org> wrote:
> >
> > [...]
> > > I'd suggest reiterating the problem you're trying to solve and
> > > enumerating the previously discussed potential solutions in order to
> > > find a proper abstraction level for this (before getting lost in
> > > implementation details).
> > >
> > The main point here is in short words: Having a device powered on or off
> > when the uart it is attached to, is used or not used anymore,
> > so the already available userspace applications do not need to be changed.
>
> So we'd end up with something in-between a kernel driver and a
> user-space solution. What about devices that need to be (partially)
> powered also when the port isn't open? A pure user-space solution would
> be able to handle all variants.
>
Well partly powered devices are at many places, And they hide that problem
from userspace, just get the open()/get() and close()/put() from there and power the
device accordingly.
So the question still remains why should the kernel hide some things and some
it should not.
If it all is in userspace, then there is still something needed in the devicetree
(if I understand correctly, every information about hardware which cannot be
auto-probed belongs into device tree) so that the userspace knows what kind of
device is at that port. So there can be a daemon powering on and off devices.
But that would break existing applications which just expect that they just need
to open/close the device.
Or you need to have some inotify handler in userspace and attach it there to
react on close() and open() of that device.
But this thing needs to have two kind of information:
1. the type of chip available to do the right powerup sequence.
2. how the chip is wired up to the cpu.
So to avoid having hardware information spread all over the table at least
these information would need to be in devicetree. But that also all feels
like a hack and hard to maintain.
Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180112/516f978d/attachment.sig>
^ permalink raw reply
* [PATCH 13/14] clk: stm32: Add clk entry for SDMMC2 on stm32F769
From: Stephen Boyd @ 2018-01-12 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515759368-16946-14-git-send-email-patrice.chotard@st.com>
On 01/12, patrice.chotard at st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> STM32F769 has 2 SDMMC port, add clock entry for the second one.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112012019.GA4059@atomide.com>
* Tony Lindgren <tony@atomide.com> [180112 01:20]:
> * Andrew Morton <akpm@linux-foundation.org> [180112 00:45]:
> > On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren <tony@atomide.com> wrote:
> >
> > > * Andrew Morton <akpm@linux-foundation.org> [180112 00:18]:
> > > > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'm seeing a considerable idle power consumption regression in
> > > > > Linux next, with power consumption for my idle test system going
> > > > > to 17.5mW compared to the usual 8mW on my test device.
> > > > >
> > > > > Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> > > > > 'akpm-current/current'") being the first bad commit.
> > > > >
> > > > > I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> > > > > have RT tasks queue in by priority in wq_add()") is good, and
> > > > > commit e2d7fe89e8ae ("Merge remote-tracking branch
> > > > > 'init_task/init_task'") is good.
> > > >
> > > > Do you mean that everything up to and including 70286688e5ad
> > > > ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
> > > > good?
> > >
> > > Yes I'm not seeing the regression in your branch at commit
> > > 70286688e5ad. I'm seeing it only with the merge commit
> > > e130bc1d00a4.
> > >
> >
> > That's weird. All I'm seeing between 70286688e5ad and end-of-mm is:
...
> Well there are some changes in merge commit e130bc1d00a4..
So it seems that the Makefile changes in Linux next merge commit
e130bc1d00a4 cause changes with CONFIG_CC_STACKPROTECTOR_AUTO=y.
With next-20180112 out now, that's now commit 3823b7cc7a5e
("Merge branch 'akpm-current/current'"). Not sure if that's a
bug or not..
Anyways, I reran my "bisect boot wait-idle measure" test with
CONFIG_CC_STACKPROTECTOR_STRONG=y selected to rule out the AUTO
option, and bisect now points to a different commit that makes
more sense for my test case.
It's commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read
on twl4030"). And that is for the PMIC on my test system, so
adding Kuninori and Mark to the thread :)
Kuninori, it seems that commit 3bb0f7c31b1a causes higher
power consumption on an idle system on omap3 using twl4030.
Reverting 3bb0f7c31b1a makes things behave again. My guess
is that twl4030_read does not do the same as snd_soc_read
in the driver?
Regards,
Tony
^ permalink raw reply
* [PATCH v3] rcutorture: Add basic ARM64 support to run scripts
From: Paul E. McKenney @ 2018-01-12 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ed0d4ad9-dd62-16dd-7e34-c913349480a9@huawei.com>
On Sat, Jan 13, 2018 at 02:32:20AM +0800, Lihao Liang wrote:
>
>
> On 2018/1/13 1:52, Paul E. McKenney wrote:
> > On Fri, Jan 12, 2018 at 06:11:32PM +0800, lianglihao at huawei.com wrote:
> >> From: Lihao Liang <lianglihao@huawei.com>
> >>
> >> This commit adds support of the qemu command qemu-system-aarch64
> >> to rcutorture.
> >>
> >> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
> >
> > This is to replace your previous patch, not to apply on top of it,
> > correct? (Either way is fine, just please let me know.)
>
> Please replace the previous one.
It has been replaced, thank you!
Thanx, Paul
> Thanks,
> Lihao.
>
> > Thanx, Paul
> >
> >> ---
> >>
> >> Comparing to the previous version, this patch lifts the limitation of
> >> maximum 8 CPUs of option "-M virt" by adding "gic-version=host" to it.
> >> This allows qemu to use the maximum CPU number supported by the actual
> >> hardware.
> >>
> >> This commit is against RCU's git branch rcu/dev
> >>
> >> commit 505b61b2ec1d ("EXP: rcu: Add debugging info to other assertion")
> >>
> >>
> >> tools/testing/selftests/rcutorture/bin/functions.sh | 17 +++++++++++++++--
> >> 1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
> >> index 07a1377..65f6655 100644
> >> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> >> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> >> @@ -136,6 +136,9 @@ identify_boot_image () {
> >> qemu-system-x86_64|qemu-system-i386)
> >> echo arch/x86/boot/bzImage
> >> ;;
> >> + qemu-system-aarch64)
> >> + echo arch/arm64/boot/Image
> >> + ;;
> >> *)
> >> echo vmlinux
> >> ;;
> >> @@ -158,6 +161,9 @@ identify_qemu () {
> >> elif echo $u | grep -q "Intel 80386"
> >> then
> >> echo qemu-system-i386
> >> + elif echo $u | grep -q aarch64
> >> + then
> >> + echo qemu-system-aarch64
> >> elif uname -a | grep -q ppc64
> >> then
> >> echo qemu-system-ppc64
> >> @@ -176,16 +182,20 @@ identify_qemu () {
> >> # Output arguments for the qemu "-append" string based on CPU type
> >> # and the TORTURE_QEMU_INTERACTIVE environment variable.
> >> identify_qemu_append () {
> >> + local console=ttyS0
> >> case "$1" in
> >> qemu-system-x86_64|qemu-system-i386)
> >> echo noapic selinux=0 initcall_debug debug
> >> ;;
> >> + qemu-system-aarch64)
> >> + console=ttyAMA0
> >> + ;;
> >> esac
> >> if test -n "$TORTURE_QEMU_INTERACTIVE"
> >> then
> >> echo root=/dev/sda
> >> else
> >> - echo console=ttyS0
> >> + echo console=$console
> >> fi
> >> }
> >>
> >> @@ -197,6 +207,9 @@ identify_qemu_args () {
> >> case "$1" in
> >> qemu-system-x86_64|qemu-system-i386)
> >> ;;
> >> + qemu-system-aarch64)
> >> + echo -machine virt,gic-version=host -cpu host
> >> + ;;
> >> qemu-system-ppc64)
> >> echo -enable-kvm -M pseries -nodefaults
> >> echo -device spapr-vscsi
> >> @@ -254,7 +267,7 @@ specify_qemu_cpus () {
> >> echo $2
> >> else
> >> case "$1" in
> >> - qemu-system-x86_64|qemu-system-i386)
> >> + qemu-system-x86_64|qemu-system-i386|qemu-system-aarch64)
> >> echo $2 -smp $3
> >> ;;
> >> qemu-system-ppc64)
> >> --
> >> 2.7.4
> >>
> >
> >
> > .
> >
>
^ permalink raw reply
* [PATCH 4/4 v7] drm/pl111: Support handling bridge timings
From: Linus Walleij @ 2018-01-12 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1a2f8244-5436-5c65-7e9e-cfe2aa257d2e@codeaurora.org>
On Fri, Jan 12, 2018 at 10:25 AM, Archit Taneja <architt@codeaurora.org> wrote:
> On 01/12/2018 01:18 PM, Linus Walleij wrote:
>>
>> If the bridge has a too strict setup time for the incoming
>> signals, we may not be fast enough and then we need to
>> compensate by outputting the signal on the inverse clock
>> edge so it is for sure stable when the bridge samples it.
>>
>> Since bridges in difference to panels does not expose their
>> connectors, make the connector optional in the display
>> setup code.
>>
>
> Since Eric has already Ack'ed it, queued to drm-misc-next so that
> the commits stay together.
Thanks man!
I have commit access but this is fine too, it's a bit like an
definitive external ACK :)
Yours,
Linus Walleij
^ permalink raw reply
* PM regression in next
From: Mark Brown @ 2018-01-12 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112190046.GD4821@atomide.com>
On Fri, Jan 12, 2018 at 11:00:46AM -0800, Tony Lindgren wrote:
> It's commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read
> on twl4030"). And that is for the PMIC on my test system, so
> adding Kuninori and Mark to the thread :)
> Kuninori, it seems that commit 3bb0f7c31b1a causes higher
> power consumption on an idle system on omap3 using twl4030.
> Reverting 3bb0f7c31b1a makes things behave again. My guess
> is that twl4030_read does not do the same as snd_soc_read
> in the driver?
As far as I can tell it should end up boiling down to the same thing but
I didn't follow through in detail, they should both bottom out in
twl_i2c_read_u8() if they hit hardware - all snd_soc_read() did was call
twl4030_read(), the patch just removes the indirection through assigning
the pointer.
Could you try deleting the attempt to read from the cache in
twl4030_read() and always go to hardware?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180112/13f1b2dc/attachment.sig>
^ permalink raw reply
* [GIT PULL] updates to soc/fsl drivers for v4.16
From: Leo Li @ 2018-01-12 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112020217.tqdjt3voqimr3ptx@localhost>
> -----Original Message-----
> From: Olof Johansson [mailto:olof at lixom.net]
> Sent: Thursday, January 11, 2018 8:02 PM
> To: Leo Li <leoyang.li@nxp.com>
> Cc: arm at kernel.org; shawnguo at kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [GIT PULL] updates to soc/fsl drivers for v4.16
>
> On Wed, Jan 10, 2018 at 05:56:36PM -0600, Li Yang wrote:
> > Hi arm-soc maintainer,
> >
> > Please merge the following tag to get updates to the soc/fsl/guts
> > driver for support of additional SoCs and more error path handling.
> >
> > Thanks,
> > Leo
> >
> >
> > The following changes since commit
> b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:
> >
> > Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git
> > tags/soc-fsl-for-4.16
> >
> > for you to fetch changes up to
> 00ce0a2304014c73c2b7915215c7b3c73e2a25aa:
> >
> > soc: fsl: guts: Add a NULL check for devm_kasprintf() (2018-01-10
> > 16:54:26 -0600)
>
> 1) This is based on much too new a release
The branch was created and the first patch was applied quite a while ago. The second patch is relatively new but very straightforward. I rebased the branch to -rc7 just before sending the pull request thinking it would be easier for you to merge. If that is not a preferred action, I will not do that again in the future.
> 2) the fact that it's based on this new a release makes me suspect it hasn't
> been sitting in linux-next either, at least not since before -rc7.
My tree is not being merged by the Linux-next right now. So you think we should ask Linux-next to add my tree too?
>
>
> Conclusion: Please resend post merge window and we'll queue it up for the
> next release. If the bugfix should go in sooner than that, I can cherry-pick
> that into our fixes. Let me know.
I know the pull request is coming a little bit late. But the two small patches are really simple and straightforward. They are not technically a fix but it will be really helpful if you can take it in this merge window. And going forward, what is your preferred time frame to send pull request to for-next?
Regards,
Leo
^ permalink raw reply
* [PATCH v2 3/7] PCI: aardvark: set host and device to the same MAX payload size
From: Bjorn Helgaas @ 2018-01-12 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112164644.5611fe3b@windsurf.lan>
On Fri, Jan 12, 2018 at 04:46:44PM +0100, Thomas Petazzoni wrote:
> On Fri, 12 Jan 2018 08:40:24 -0600, Bjorn Helgaas wrote:
> > The Device Control MPS field defaults to 128 bytes. Generic software
> > can only change that default if it knows that every element that might
> > receive a packet from the device can handle it. In this case, we have
> > no information about what the invisible Root Port can handle, so I
> > would argue that we cannot change MPS.
> >
> > In the lspci above, MPS is set to 256 bytes. If that was done by
> > firmware, it might be safe because it knows things about the Root Port
> > that Linux doesn't. But I don't think the Linux PCI core could set it
> > to 256.
>
> So you're suspecting that the firmware/bootloader has configured the
> MPS on the E1000E device to 256 bytes ?
I didn't word that very well. It looks like *something* set it to
256, but I don't know what. It's possible Linux did, but I think that
would be a bug and should be fixed. We'd have to instrument the code
or analyze it more closely than I have.
> Isn't it dangerous for the kernel to rely on the firmware/bootloader
> configuration ? Indeed, the firmware/bootloader might have configured
> MPS to X bytes on the endpoint, but when the kernel boots and
> initializes the PCIe controller, its sets the PCIe controller MPS to Y
> bytes, with Y > X.
>
> > ASPM L0s is similar. We should only enable L0s if we can tell that
> > both ends of the link support it. If there's no Root Port, we don't
> > have any ASPM capability information for the upstream end of the link,
> > so we shouldn't enable ASPM at all.
>
> Well, even without the Root Port, we are able to use the endpoint
> configuration space to figure out whether it supports L0s, and adjust
> the root complex configuration accordingly. This is what our patch is
> doing for MPS, and which could be done similarly for L0s, no?
Yes, this is where it would get machine-specific. I don't know how
that should be structured, or even whether it's really worthwhile. I
think the core should make it *work* with the least-common-denominator
approach, but I'm not convinced that a lot of effort should be put
into optimizing a topology that doesn't follow the spec. A driver
could do this outside the core, but I think it would be better to put
the effort into making the topology more standard.
Why exactly *doesn't* Aardvark expose the Root Port? I assume it does
actually exist, since there is actually a link leading to the slot,
and there has to be *something* at the upstream end of that link.
> > I had the impression that these patches were required for correct
> > functionality, not just to improve performance. But maybe I
> > misunderstood?
>
> I don't myself have the device that wasn't working, and that this patch
> got to work, so I can't double check myself. However, indeed, I was
> told that without this fix, some devices would not work.
>
> One question: is it valid/working to have the root complex configured
> with MPS = 128 bytes but the endpoint configured with MPS = 256 or 512
> bytes ? Or should the MPS value be strictly equal on both sides ?
Per PCIe r4.0, sec 2.2.2, a device cannot transmit a TLP with a
payload larger than its MPS. A device receiving a TLP with a payload
larger than its MPS must treat the TLP as malformed.
I think that means MPS really should be set the same on both sides so
the device can do both DMA reads and writes safely.
> Depending on your answer, there are two options:
>
> - It is a valid situation to have a root complex MPS lower than the
> endpoint MPS. In this case, we could for now simply unconditionally
> set the MPS to 128 bytes in the root complex, as a fix to get all
> devices working. And then separately, work on improving performance
> by increasing the MPS according to the endpoint capabilities.
>
> - It is not valid for the root complex MPS to be different than the
> endpoint MPS. In this case, then I don't see how we can do things
> differently than the proposed patch: we have to see what the
> endpoint MPS is, and adjust the root complex MPS accordingly.
> Indeed, the bootloader/firmware might have changed the endpoint MPS
> so that it is no longer the default of 128 bytes.
All devices are guaranteed to support MPS = 128 bytes, so if you set
the Root Port to that in the driver, we should be able to make the PCI
core leave (or set, if necessary) all devices with MPS = 128.
I think we should start with that first, then worry about performance
optimizations separately. I guess I'm still just shaking my head over
the invisible Root Port mystery. I think the other cases I know about
are related to virtualization, where I can sort of understand why the
Root Port is missing, but I don't think that's the situation here.
Bjorn
^ 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