* [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver
From: Jonathan Richardson @ 2016-10-31 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031013848.4vi2544tb5cs65nk@rob-hp-laptop>
On 16-10-30 06:38 PM, Rob Herring wrote:
> On Mon, Oct 24, 2016 at 12:12:02PM -0700, Jonathan Richardson wrote:
>> From: Jonathan Richardson <jonathar@broadcom.com>
>>
>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Oza Pawandeep <oza@broadcom.com>
>> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> ---
>> Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
>> new file mode 100644
>> index 0000000..6462e12
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
>> @@ -0,0 +1,17 @@
>> +Broadcom OTP memory controller
>> +
>> +Required Properties:
>> +- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
>> + in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
>> + generation Broadcom OTPC which is used in SoC's such as Stingray and supports
>> + 64-bit read/write.
>
> These should be SoC specific. While I'd guess this block is simple
> enough, having the SoC can define what all the bits are. Yes, there is a
> binding to define those, but you may not use that.
Hi Rob. This block isn't SoC specific. It is used on multiple SoC's.
There are older SoC's using v1 that we may upstream drivers for in the
future. v1 isn't specific to cygnus/iproc and v2 isn't specific to stingray.
>
>
>> +- reg: Base address of the OTP controller.
>> +- brcm,ocotp-size: Amount of memory available, in 32 bit words
>> +
>> +Example:
>> +
>> +otp: otp at 0301c800 {
>> + compatible = "brcm,ocotp";
>> + reg = <0x0301c800 0x2c>;
>> + brcm,ocotp-size = <2048>;
>> +};
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Matt Ranostay @ 2016-10-31 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKzfze_rv29gwuBGctwTONyw8Oy6fwE+xcN0HMh-ZPB47HKzuQ@mail.gmail.com>
On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay <mranostay@gmail.com> wrote:
> On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
>>> Pavel + Sebastian this is the patchset that need I some input on :)
>>
>> Better then previous one.
>>
>> But my version of bq27xxx_battery.c already contains this:
>
> This is for allowing udev rule to set the properties as well.
> otherwise a kinda crude RUN = " echo value >
> /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
Any thoughts on this?
Thanks,
Matt
>
>>
>> static const struct kernel_param_ops param_ops_poll_interval = {
>> .get = param_get_uint,
>> .set = poll_interval_param_set,
>> };
>>
>> ...so it should be possible to set poll interval already.
>>
>> Pavel
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 4/5] ARM: dts: da850-lcdk: enable mstpri and ddrctl nodes
From: Laurent Pinchart @ 2016-10-31 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-5-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
Thank you for the patch.
On Monday 31 Oct 2016 15:45:37 Bartosz Golaszewski wrote:
> Enable the MSTPRI configuration and DDR2/mDDR memory controller
> nodes on da850-lcdk. This is needed in order to adjust the memory
> throughput constraints for better tilcdc support.
Is there a reason not to enable these unconditionally in da850.dtsi (or rather
not disabling them) instead of handling it per board ?
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index 4747629..b39796e 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -243,3 +243,11 @@
> };
> };
> };
> +
> +&mstpri {
> + status = "okay";
> +};
> +
> +&ddrctl {
> + status = "okay";
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pali Rohár @ 2016-10-31 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ_EiSRzmQHLP2PTfzsLF4uWgYgCiRGsSk=MHbtOC5rgXnnFpw@mail.gmail.com>
On Monday 31 October 2016 21:22:18 Matt Ranostay wrote:
> On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay <mranostay@gmail.com>
> wrote:
> > On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
> >>> Pavel + Sebastian this is the patchset that need I some input on
> >>> :)
> >>
> >> Better then previous one.
> >
> >> But my version of bq27xxx_battery.c already contains this:
> > This is for allowing udev rule to set the properties as well.
> > otherwise a kinda crude RUN = " echo value >
> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> Any thoughts on this?
Isn't sysfs /sys/module/bq27xxx_battery/parameters/poll_interval
attribute what should be used to change module parameters like
poll_interval?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/aa2d9abc/attachment.sig>
^ permalink raw reply
* [PATCH V2 6/6] arm64: Add uprobe support
From: Catalin Marinas @ 2016-10-31 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_Gup2-yWbKK7QpMjJv7M6oNdV8Mz10wxWaS8ojzR4s8wv=g@mail.gmail.com>
Hi Pratyush,
On Mon, Oct 31, 2016 at 02:10:43PM +0530, Pratyush Anand wrote:
> On Sun, Oct 30, 2016 at 7:39 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Tue, Sep 27, 2016 at 01:18:00PM +0530, Pratyush Anand wrote:
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/probes/uprobes.c
> >> @@ -0,0 +1,221 @@
> >> +/*
> >> + * Copyright (C) 2014-2016 Pratyush Anand <panand@redhat.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +#include <linux/highmem.h>
> >> +#include <linux/ptrace.h>
> >> +#include <linux/uprobes.h>
> >> +#include <asm/cacheflush.h>
> >> +
> >> +#include "decode-insn.h"
> >> +
> >> +#define UPROBE_INV_FAULT_CODE UINT_MAX
> >> +
> >> +bool is_trap_insn(uprobe_opcode_t *insn)
> >> +{
> >> + return false;
> >> +}
> >
> > On the previous series, I had a comment left unanswered with regards to
> > always returning false in is_trap_insn():
> >
> > Looking at handle_swbp(), if we hit a breakpoint for which we don't have
> > a valid uprobe, this function currently sends a SIGTRAP. But if
> > is_trap_insn() returns false always, is_trap_at_addr() would return 0 in
> > this case so the SIGTRAP is never issued.
>
> A agreed on this that the older implementation i.e. the default one of
> is_trap_insn() is better for the time being. I sent out V2 before your
> last comment on it in V1 :(.
Thinking some more about this, the default is_trap_insn() still seems
better. It may return true occasionally for 32-bit tasks but we don't
care anyway because the subsequent arch_uprobe_analyze_insn() would
prevent the installation of the uprobe. However, always returning false
in is_trap_insn() would confuse handle_swbp() if you install uprobes in
an already debugged task.
> probably 'strtle r0, [r0], #160' would have the closest matching
> aarch32 instruction wrt BRK64_OPCODE_UPROBES(0xd42000A0). But that too
> seems a bad aarch32 instruction. So, there might not be any aarch32
> instruction which will match to uprobe BRK instruction.
As I said above, even if it matches, we don't support uprobes for 32-bit
(caught by the subsequent test).
> Therefore, if I send a V3 by removing aacrh64 is_trap_insn(), would
> that be acceptable, or do you see any other issue with this patch
> series? If there is anything else, I would address that in V3 as well.
I think I have one minor comment on arch_uprobe_analyze_insn() and v3
should look ok.
--
Catalin
^ permalink raw reply
* [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Nishanth Menon @ 2016-10-31 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c58712-bc00-ed05-9d1d-42e31397a70c@ti.com>
On 10/31/2016 07:50 AM, Tero Kristo wrote:
[...]
>>> +pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> +
>>> + k2g_clks: k2g_clks {
>>
>> Use "clocks" for node name instead.
>>
>>> + compatible = "ti,k2g-sci-clk";
>>
>> I'm starting to think all these child nodes for SCI are pointless. Is
>> there any reason why the parent node can't be the clock provider (along
>> with all the other providers it acks as)?
>
> I believe the only reason to keep them separate is to have kernel side
> of things modular. If we have separate nodes, the drivers can be probed
> separately.
>
> If not, we need to build one huge blob with all the features in it, so
> the main driver can probe everything in one go, with annoying
> back-and-forth callbacks in place (assuming we still want to keep stuff
> somehow modular.)
Documentation/devicetree/bindings/arm/arm,scpi.txt follows the same
solution as well, right? There is indeed additional nodes coming in -
such as reset, pd etc.. I cant see why it is different for sci clk..
not to mention the driver mess it results in.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH V2 6/6] arm64: Add uprobe support
From: Catalin Marinas @ 2016-10-31 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41cc70043792e65cbc3b4cc4ad7fbf6379afa550.1474960629.git.panand@redhat.com>
On Tue, Sep 27, 2016 at 01:18:00PM +0530, Pratyush Anand wrote:
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct *mm,
> + unsigned long addr)
> +{
> + probe_opcode_t insn;
> +
> + /* TODO: Currently we do not support AARCH32 instruction probing */
> + if (test_bit(TIF_32BIT, &mm->context.flags))
> + return -EINVAL;
This should be -ENOTSUPP.
--
Catalin
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2016-10-31 20:34 UTC (permalink / raw)
To: linux-arm-kernel
I inspired by this issue [1] i build up a slightly modified setup with a
Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 Prolific
PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
only tries to open all ttyUSB devices one after the other.
Unfortunately the complete system stuck after opening the first ttyUSB device (
heartbeat LED stop blinking, no reaction to debug UART). The only way to
reanimate the system is to powerdown the USB hub with the USB to serial
convertors.
[1] - https://github.com/raspberrypi/linux/issues/1692
[2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
pi at raspberrypi:~$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx,
480M
|__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
|__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
Driver=pl2303, 12M
pi at raspberrypi:~$ ./usb_test
idle
opening [/dev/ttyUSB0] ok
[ 232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
[usb_test:522]
[ 232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
[ 232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
4.9.0-rc3+ #33
[ 232.678486] Hardware name: BCM2835
[ 232.678498] task: cab54e40 task.stack: c688c000
[ 232.678520] PC is at __do_softirq+0x68/0x2a8
[ 232.678538] LR is at irq_exit+0xb8/0x120
[ 232.678552] pc : [<c01014d0>] lr : [<c0121270>] psr: 60000113
sp : c688da60 ip : c688daa8 fp : c688daa4
[ 232.678560] r10: c0b7f800 r9 : c688c000 r8 : 00400000
[ 232.678567] r7 : 0000000a r6 : cb802400 r5 : 00000000 r4 : 00000001
[ 232.678575] r3 : 00000000 r2 : 00000100 r1 : 00400000 r0 : 00000000
[ 232.678585] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 232.678593] Control: 00c5387d Table: 068a4008 DAC: 00000051
[ 232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
4.9.0-rc3+ #33
[ 232.678609] Hardware name: BCM2835
[ 232.678667] [<c010ecc0>] (unwind_backtrace) from [<c010bc28>]
(show_stack+0x20/0x24)
[ 232.678695] [<c010bc28>] (show_stack) from [<c03684e0>]
(dump_stack+0x20/0x28)
[ 232.678718] [<c03684e0>] (dump_stack) from [<c0108ee4>] (show_regs+0x1c/0x20)
[ 232.678752] [<c0108ee4>] (show_regs) from [<c018ea00>]
(watchdog_timer_fn+0x140/0x19c)
[ 232.678779] [<c018ea00>] (watchdog_timer_fn) from [<c015eefc>]
(__hrtimer_run_queues.constprop.3+0xec/0x210)
[ 232.678798] [<c015eefc>] (__hrtimer_run_queues.constprop.3) from [<c015f210>]
(hrtimer_interrupt+0xa4/0x1cc)
[ 232.678827] [<c015f210>] (hrtimer_interrupt) from [<c04eff58>]
(bcm2835_time_interrupt+0x40/0x48)
[ 232.678865] [<c04eff58>] (bcm2835_time_interrupt) from [<c01537ec>]
(__handle_irq_event_percpu+0x68/0x1b8)
[ 232.678891] [<c01537ec>] (__handle_irq_event_percpu) from [<c0153968>]
(handle_irq_event_percpu+0x2c/0x68)
[ 232.678915] [<c0153968>] (handle_irq_event_percpu) from [<c01539dc>]
(handle_irq_event+0x38/0x4c)
[ 232.678939] [<c01539dc>] (handle_irq_event) from [<c0156df8>]
(handle_level_irq+0xc4/0xf8)
[ 232.678960] [<c0156df8>] (handle_level_irq) from [<c0152fd8>]
(generic_handle_irq+0x28/0x38)
[ 232.678983] [<c0152fd8>] (generic_handle_irq) from [<c0153144>]
(__handle_domain_irq+0x90/0xb8)
[ 232.679004] [<c0153144>] (__handle_domain_irq) from [<c01013f4>]
(bcm2835_handle_irq+0x30/0x48)
[ 232.679022] [<c01013f4>] (bcm2835_handle_irq) from [<c010c7cc>]
(__irq_svc+0x6c/0x90)
[ 232.679031] Exception stack(0xc688da10 to 0xc688da58)
[ 232.679044] da00: 00000000 00400000
00000100 00000000
[ 232.679062] da20: 00000001 00000000 cb802400 0000000a 00400000 c688c000
c0b7f800 c688daa4
[ 232.679078] da40: c688daa8 c688da60 c0121270 c01014d0 60000113 fffff000000
c687a300 c9374900 ca918b00 caff1200 c688db84
[ 232.679235] db20: c688db28 c688db40 c04a1cf8 c049cb64 60000013 ffffffff
[ 232.679272] [<c010c7cc>] (__irq_svc) from [<c049cb64>]
(_dwc2_hcd_urb_enqueue+0x414/0x560)
[ 232.679302] [<c049cb64>] (_dwc2_hcd_urb_enqueue) from [<c04849ac>]
(usb_hcd_submit_urb+0x704/0x8c4)
[ 232.679327] [<c04849ac>] (usb_hcd_submit_urb) from [<c048628c>]
(usb_submit_urb+0x438/0x4e0)
[ 232.679358] [<c048628c>] (usb_submit_urb) from [<c04a9d60>]
(usb_serial_generic_submit_read_urb+0x50/0xc8)
[ 232.679382] [<c04a9d60>] (usb_serial_generic_submit_read_urb) from
[<c04aa0a8>] (usb_serial_generic_submit_read_urbs+0x28/0x70)
[ 232.679407] [<c04aa0a8>] (usb_serial_generic_submit_read_urbs) from
[<c04aa298>] (usb_serial_generic_open+0x44/0x4c)
[ 232.679435] [<c04aa298>] (usb_serial_generic_open) from [<c04aebc4>]
(pl2303_open+0xc0/0xe0)
[ 232.679458] [<c04aebc4>] (pl2303_open) from [<c04a744c>]
(serial_port_activate+0x54/0x8c)
[ 232.679486] [<c04a744c>] (serial_port_activate) from [<c03c4014>]
(tty_port_open+0x84/0xd4)
[ 232.679509] [<c03c4014>] (tty_port_open) from [<c04a7d40>]
(serial_open+0x34/0x5c)
[ 232.679546] [<c04a7d40>] (serial_open) from [<c03bd3a8>]
(tty_open+0x380/0x534)
[ 232.679578] [<c03bd3a8>] (tty_open) from [<c021e188>]
(chrdev_open+0x120/0x14c)
[ 232.679612] [<c021e188>] (chrdev_open) from [<c0217368>]
(do_dentry_open+0x1b8/0x304)
[ 232.679638] [<c0217368>] (do_dentry_open) from [<c021876c>]
(vfs_open+0x7c/0x80)
[ 232.679663] [<c021876c>] (vfs_open) from [<c022834c>]
(path_openat+0xb60/0xd88)
[ 232.679682] [<c022834c>] (path_openat) from [<c02285bc>]
(do_filp_open+0x48/0x94)
[ 232.679704] [<c02285bc>] (do_filp_open) from [<c0218af4>]
(do_sys_open+0x12c/0x1cc)
[ 232.679728] [<c0218af4>] (do_sys_open) from [<c0218bc4>] (SyS_open+0x30/0x34)
[ 232.679754] [<c0218bc4>] (SyS_open) from [<c0108280>]
(ret_fast_syscall+0x0/0x3c)
[ 233.852571] usb 1-1.2: clear tt 1 (9063) error -110
[ 233.853046] usb 1-1.2.1: clear tt 1 (9073) error -110
[ 234.892554] usb 1-1.2.1: clear tt 1 (9071) error -110
[ 234.892995] usb 1-1.2: clear tt 1 (9061) error -110
[ 235.932574] usb 1-1.2.1: clear tt 1 (9073) error -110
[ 235.933542] usb 1-1.2: clear tt 1 (9063) error -110
[ 236.972595] usb 1-1.2.1: clear tt 1 (9071) error -110
[ 236.973235] usb 1-1.2: clear tt 1 (9061) error -110
[ 238.012573] usb 1-1.2: clear tt 1 (9063) error -110
[ 238.013052] usb 1-1.2.1: clear tt 1 (9073) error -110
[ 238.013456] hub 1-1:1.0: hub_ext_port_status failed (err = -110)
[ 239.052567] usb 1-1.2.1: clear tt 1 (9071) error -110
[ 239.053076] usb 1-1.2: clear tt 1 (9061) error -110
[ 240.092573] usb 1-1.2: clear tt 1 (9063) error -110
[ 240.093050] usb 1-1.2.1: clear tt 1 (9073) error -110
[ 240.239643] usb 1-1.2.1: USB disconnect, device number 5
[ 240.239685] usb 1-1.2.1.2: USB disconnect, device number 7
[ 240.262707] usb 1-1.2: clear tt 1 (9061) error -71
[ 240.263123] usb 1-1.2.1: clear tt 1 (9071) error -71
[ 240.263708] usb 1-1.2: USB disconnect, device number 4
[ 694304] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 251.694645] pl2303 1-1.2.2:1.0: device disconnected
[ 251.704668] usb 1-1.2.3: USB disconnect, device number 8
[ 251.706468] pl2303 ttyUSB2: pl2303 converter now disconnected from ttyUSB2
[ 251.706894] pl2303 1-1.2.3:1.0: device disconnected
[ 251.714720] usb 1-1.2.4: USB disconnect, device number 10
[ 251.733019] pl2303 ttyUSB4: pl2303 converter now disconnected from ttyUSB4
[ 251.733459] pl2303 1-1.2.4:1.0: device disconnected
[ 251.852767] hub 1-1.2:1.0: activate --> -19
^ permalink raw reply
* [PATCH v1 2/3] nvmem: Add the Broadcom OTP controller driver
From: Florian Fainelli @ 2016-10-31 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a85d1574-8d4b-e0bf-7340-7eab30deef37@broadcom.com>
On 10/31/2016 12:55 PM, Scott Branden wrote:
> Florian,
>
> On 16-10-31 07:23 AM, Srinivas Kandagatla wrote:
>>
>> On 24/10/16 20:12, Jonathan Richardson wrote:
>>> From: Jonathan Richardson <jonathar@broadcom.com>
>>>
>>> Add support for 32 and 64-bit versions of Broadcom's On-Chip OTP
>>> controller. These controllers are used on SoC's such as Cygnus and
>>> Stingray.
>>>
>>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>>> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> Signed-off-by: Oza Pawandeep <oza@broadcom.com>
>>> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>>> ---
>>> drivers/nvmem/Kconfig | 12 ++
>>> drivers/nvmem/Makefile | 2 +
>>> drivers/nvmem/bcm-ocotp.c | 335
>>> ++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 349 insertions(+)
>>> create mode 100644 drivers/nvmem/bcm-ocotp.c
>>
>>
>> I can pick this patch along with dt bindings document, but dts patch has
>> to go via arm-soc tree.
>
> Can you pick up [PATCH v1 3/3] ARM: dts: Add node from Broadcom OTP
> controller driver?
As soon as we get Rob's acked-by for Patch 1, sure.
--
Florian
^ permalink raw reply
* [PATCH v2 4/5] ARM: dts: da850-lcdk: enable mstpri and ddrctl nodes
From: Kevin Hilman @ 2016-10-31 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12222113.L5elJM2tqN@avalon>
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Monday 31 Oct 2016 15:45:37 Bartosz Golaszewski wrote:
>> Enable the MSTPRI configuration and DDR2/mDDR memory controller
>> nodes on da850-lcdk. This is needed in order to adjust the memory
>> throughput constraints for better tilcdc support.
>
> Is there a reason not to enable these unconditionally in da850.dtsi (or rather
> not disabling them) instead of handling it per board ?
Right. They should be enabled by default in DT. The drivers already
have board-specific compatible checks.
Kevin
^ permalink raw reply
* [PATCH v8 0/3] da8xx USB PHY platform devices and clocks
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
I reworked the "[PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node" and
"[PATCH v6 5/5] ARM: DTS: da850: Add usb phy node" patches that were dropped
from linux-davinci into the new "ARM: dts: da850: Add cfgchip syscon node"
patch. This should be OK unless it is decided that the BayLibre guys should
rework it so that the entire SYSCFG0 is a single syscon device. I don't see
any compelling reason to do that though.
v8 changes:
* Dropped v7 patches that have been accepted into linux-davinci already
* New patch for CFGCHIP syscon/USB PHY DT node
* Rebased other patches
v7 changes:
* Dropped v6 patches that have been accepted into linux-davinci already
* New patch for adding device names to clock lookup tables
* Picked up related patch from Axel Haslam for registering USB PHY clocks on
device tree boards and added error checking to to that patch
* Rebased on latest linux-davinci + linux-next
* Added devices instead of NULL in clk_get() where appropriate usb-da8xx.c
* Re-ordered patches so that they apply/build cleanly
v6 changes:
* Combine "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
from the "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx" series with
the "ARM: davinci: da8xx: add usb phy clocks" patch in this series.
* Change the syscon and da8xx-usb-phy device ids to -1.
v5 changes: renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate
v4 changes: fix strict checkpatch complaint
v3 changes:
* Fixed the davinci device tree declarations to use the preferred DT address
convention so that the items I have added can be correct too.
* Moved that davinci clock init so that we don't have to call ioremap in the
clock mux functions.
* Added a new "syscon" device for the CFGCHIP registers. This is used by the
USB PHY driver and will be used in the future in common clock framework
drivers.
* USB clocks are moved to a common file instead of having duplicated code.
* PHY driver uses syscon for CFGCHIP registers instead of using them directly.
Axel Haslam (1):
ARM: davinci: da8xx: register USB PHY clocks in the DT file
David Lechner (2):
ARM: dts: da850: Add cfgchip syscon node
ARM: davinci: da8xx: add usb phy clocks
arch/arm/boot/dts/da850.dtsi | 10 ++
arch/arm/mach-davinci/board-da830-evm.c | 31 +---
arch/arm/mach-davinci/board-omapl138-hawk.c | 15 +-
arch/arm/mach-davinci/da8xx-dt.c | 12 ++
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
arch/arm/mach-davinci/usb-da8xx.c | 267 ++++++++++++++++++++++++++--
6 files changed, 296 insertions(+), 42 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
for the USB PHY that is part of this range of registers.
Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
the the USB PHY driver.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
arch/arm/mach-davinci/da8xx-dt.c | 1 +
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4c83613..2534aab 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -209,6 +209,16 @@
};
};
+ cfgchip: chip-controller at 1417c {
+ compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+ reg = <0x1417c 0x14>;
+
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ };
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index aec569f9..20fa842 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
+ OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH v8 2/3] ARM: davinci: da8xx: add usb phy clocks
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files and
replaced with the new clock registration functions.
This also removes the #if IS_ENABLED(CONFIG_USB_MUSB_HDRC) around the musb
declaration and renames the musb platform device so that we can reference
it from the usb20 clock even if the musb device is not used.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 31 +---
arch/arm/mach-davinci/board-omapl138-hawk.c | 15 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +
arch/arm/mach-davinci/usb-da8xx.c | 267 ++++++++++++++++++++++++++--
4 files changed, 274 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 53172ad..5db0901 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -18,7 +18,6 @@
#include <linux/i2c.h>
#include <linux/i2c/pcf857x.h>
#include <linux/platform_data/at24.h>
-#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -108,30 +107,18 @@ static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
static __init void da830_evm_usb_init(void)
{
- u32 cfgchip2;
int ret;
- /*
- * Set up USB clock in the CFGCHIP2 register.
- * FYI: CFGCHIP2 is 0x0000ef00 initially.
- */
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
- /* USB2.0 PHY reference clock is 24 MHz */
- cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
-
- /*
- * Select internal reference clock for USB 2.0 PHY
- * and use it as a clock source for USB 1.1 PHY
- * (this is the default setting anyway).
- */
- cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
- cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
-
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
-
/* USB_REFCLKIN is not used. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
+
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
ret = da8xx_register_usb_phy();
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 67477ca..a4e8726 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,7 +13,6 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/gpio.h>
-#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/regulator/machine.h>
@@ -245,7 +244,6 @@ static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
static __init void omapl138_hawk_usb_init(void)
{
int ret;
- u32 cfgchip2;
ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
if (ret) {
@@ -253,12 +251,15 @@ static __init void omapl138_hawk_usb_init(void)
return;
}
- /* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
+ __func__, ret);
- cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
- cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
- __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: USB 1.1 PHY CLK registration failed: %d\n",
+ __func__, ret);
ret = da8xx_register_usb_phy();
if (ret)
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 5e07d06..43322be 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -92,6 +92,9 @@ int da8xx_register_watchdog(void);
int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
+int da8xx_register_usb_refclkin(int rate);
+int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
+int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
int da8xx_register_emac(void);
int da8xx_register_uio_pruss(void);
int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index 4bb1903..b010e5f 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -1,24 +1,38 @@
/*
* DA8xx USB
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/init.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/phy/phy.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_device.h>
#include <linux/usb/musb.h>
+#include <mach/clock.h>
#include <mach/common.h>
#include <mach/cputype.h>
#include <mach/da8xx.h>
#include <mach/irqs.h>
+#include "clock.h"
+
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
.id = -1,
+ .dev = {
+ /*
+ * Setting init_name so that clock lookup will work in
+ * da8xx_register_usb11_phy_clk() even if this device is not
+ * registered yet.
+ */
+ .init_name = "da8xx-usb-phy",
+ },
};
int __init da8xx_register_usb_phy(void)
@@ -26,8 +40,6 @@ int __init da8xx_register_usb_phy(void)
return platform_device_register(&da8xx_usb_phy);
}
-#if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
-
static struct musb_hdrc_config musb_config = {
.multipoint = true,
.num_eps = 5,
@@ -56,10 +68,15 @@ static struct resource da8xx_usb20_resources[] = {
static u64 usb_dmamask = DMA_BIT_MASK(32);
-static struct platform_device usb_dev = {
+static struct platform_device da8xx_usb20_dev = {
.name = "musb-da8xx",
.id = -1,
.dev = {
+ /*
+ * Setting init_name so that clock lookup will work in
+ * usb20_phy_clk_enable() even if this device is not registered.
+ */
+ .init_name = "musb-da8xx",
.platform_data = &usb_data,
.dma_mask = &usb_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
@@ -73,18 +90,9 @@ int __init da8xx_register_usb20(unsigned int mA, unsigned int potpgt)
usb_data.power = mA > 510 ? 255 : mA / 2;
usb_data.potpgt = (potpgt + 1) / 2;
- return platform_device_register(&usb_dev);
-}
-
-#else
-
-int __init da8xx_register_usb20(unsigned int mA, unsigned int potpgt)
-{
- return 0;
+ return platform_device_register(&da8xx_usb20_dev);
}
-#endif /* CONFIG_USB_MUSB_HDRC */
-
static struct resource da8xx_usb11_resources[] = {
[0] = {
.start = DA8XX_USB1_BASE,
@@ -116,3 +124,236 @@ int __init da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata)
da8xx_usb11_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_usb11_device);
}
+
+static struct clk usb_refclkin = {
+ .name = "usb_refclkin",
+ .set_rate = davinci_simple_set_rate,
+};
+
+static struct clk_lookup usb_refclkin_lookup =
+ CLK(NULL, "usb_refclkin", &usb_refclkin);
+
+/**
+ * da8xx_register_usb_refclkin - register USB_REFCLKIN clock
+ *
+ * @rate: The clock rate in Hz
+ *
+ * This clock is only needed if the board provides an external USB_REFCLKIN
+ * signal, in which case it will be used as the parent of usb20_phy_clk and/or
+ * usb11_phy_clk.
+ */
+int __init da8xx_register_usb_refclkin(int rate)
+{
+ int ret;
+
+ usb_refclkin.rate = rate;
+ ret = clk_register(&usb_refclkin);
+ if (ret)
+ return ret;
+
+ clkdev_add(&usb_refclkin_lookup);
+
+ return 0;
+}
+
+static void usb20_phy_clk_enable(struct clk *clk)
+{
+ struct clk *usb20_clk;
+ int err;
+ u32 val;
+ u32 timeout = 500000; /* 500 msec */
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
+ if (IS_ERR(usb20_clk)) {
+ pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
+ return;
+ }
+
+ /* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
+ err = clk_prepare_enable(usb20_clk);
+ if (err) {
+ pr_err("failed to enable usb20 clk: %d\n", err);
+ clk_put(usb20_clk);
+ return;
+ }
+
+ /*
+ * Turn on the USB 2.0 PHY, but just the PLL, and not OTG. The USB 1.1
+ * host may use the PLL clock without USB 2.0 OTG being used.
+ */
+ val &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
+ val |= CFGCHIP2_PHY_PLLON;
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ while (--timeout) {
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ if (val & CFGCHIP2_PHYCLKGD)
+ goto done;
+ udelay(1);
+ }
+
+ pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
+done:
+ clk_disable_unprepare(usb20_clk);
+ clk_put(usb20_clk);
+}
+
+static void usb20_phy_clk_disable(struct clk *clk)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+ val |= CFGCHIP2_PHYPWRDN;
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+}
+
+static int usb20_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the mux depending on the parent clock. */
+ if (parent == &usb_refclkin) {
+ val &= ~CFGCHIP2_USB2PHYCLKMUX;
+ } else if (strcmp(parent->name, "pll0_aux_clk") == 0) {
+ val |= CFGCHIP2_USB2PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 2.0 PHY clock\n");
+ return -EINVAL;
+ }
+
+ /* reference frequency also comes from parent clock */
+ val &= ~CFGCHIP2_REFFREQ_MASK;
+ switch (clk_get_rate(parent)) {
+ case 12000000:
+ val |= CFGCHIP2_REFFREQ_12MHZ;
+ break;
+ case 13000000:
+ val |= CFGCHIP2_REFFREQ_13MHZ;
+ break;
+ case 19200000:
+ val |= CFGCHIP2_REFFREQ_19_2MHZ;
+ break;
+ case 20000000:
+ val |= CFGCHIP2_REFFREQ_20MHZ;
+ break;
+ case 24000000:
+ val |= CFGCHIP2_REFFREQ_24MHZ;
+ break;
+ case 26000000:
+ val |= CFGCHIP2_REFFREQ_26MHZ;
+ break;
+ case 38400000:
+ val |= CFGCHIP2_REFFREQ_38_4MHZ;
+ break;
+ case 40000000:
+ val |= CFGCHIP2_REFFREQ_40MHZ;
+ break;
+ case 48000000:
+ val |= CFGCHIP2_REFFREQ_48MHZ;
+ break;
+ default:
+ pr_err("Bad parent clock rate on USB 2.0 PHY clock\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb20_phy_clk = {
+ .name = "usb20_phy",
+ .clk_enable = usb20_phy_clk_enable,
+ .clk_disable = usb20_phy_clk_disable,
+ .set_parent = usb20_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb20_phy_clk_lookup =
+ CLK("da8xx-usb-phy", "usb20_phy", &usb20_phy_clk);
+
+/**
+ * da8xx_register_usb20_phy_clk - register USB0PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "pll0_aux" if false.
+ */
+int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb20_phy_clk.parent = parent;
+ ret = clk_register(&usb20_phy_clk);
+ if (!ret)
+ clkdev_add(&usb20_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
+
+static int usb11_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ u32 val;
+
+ val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* Set the USB 1.1 PHY clock mux based on the parent clock. */
+ if (parent == &usb20_phy_clk) {
+ val &= ~CFGCHIP2_USB1PHYCLKMUX;
+ } else if (parent == &usb_refclkin) {
+ val |= CFGCHIP2_USB1PHYCLKMUX;
+ } else {
+ pr_err("Bad parent on USB 1.1 PHY clock\n");
+ return -EINVAL;
+ }
+
+ writel(val, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ return 0;
+}
+
+static struct clk usb11_phy_clk = {
+ .name = "usb11_phy",
+ .set_parent = usb11_phy_clk_set_parent,
+};
+
+static struct clk_lookup usb11_phy_clk_lookup =
+ CLK("da8xx-usb-phy", "usb11_phy", &usb11_phy_clk);
+
+/**
+ * da8xx_register_usb11_phy_clk - register USB1PHYCLKMUX clock
+ *
+ * @use_usb_refclkin: Selects the parent clock - either "usb_refclkin" if true
+ * or "usb20_phy" if false.
+ */
+int __init da8xx_register_usb11_phy_clk(bool use_usb_refclkin)
+{
+ struct clk *parent;
+ int ret = 0;
+
+ if (use_usb_refclkin)
+ parent = clk_get(NULL, "usb_refclkin");
+ else
+ parent = clk_get(&da8xx_usb_phy.dev, "usb20_phy");
+ if (IS_ERR(parent))
+ return PTR_ERR(parent);
+
+ usb11_phy_clk.parent = parent;
+ ret = clk_register(&usb11_phy_clk);
+ if (!ret)
+ clkdev_add(&usb11_phy_clk_lookup);
+
+ clk_put(parent);
+
+ return ret;
+}
--
2.7.4
^ permalink raw reply related
* [PATCH v8 3/3] ARM: davinci: da8xx: register USB PHY clocks in the DT file
From: David Lechner @ 2016-10-31 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-1-git-send-email-david@lechnology.com>
From: Axel Haslam <ahaslam@baylibre.com>
The usb20_phy clock needs to be registered for the driver to be able
to get and enable a clock. Currently the usb phy clocks are registered
form board files, which will not be called during a device tree based
boot.
To be able to probe correctly usb form a device tree boot, register
the usb phy clocks form the DT specific init.
Unfourtunatly, davinci does not have proper clock support on device tree
yet, so by registering the clock form de DT specific file we are
forced to hardcode the parent clock, and cannot select refclkin as
parent for any of the phy clocks of the da850 family.
As none of the current da850 based boards currently in mainline use
refclkin as source. I guess we can live with this limitation until clocks
are correctly represented through CCF/device tree.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
[Added error checking]
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 20fa842..230c151 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -49,6 +49,17 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
+ int ret;
+
+ ret = da8xx_register_usb20_phy_clk(false);
+ if (ret)
+ pr_warn("%s: registering USB 2.0 PHY clock failed: %d",
+ __func__, ret);
+ ret = da8xx_register_usb11_phy_clk(false);
+ if (ret)
+ pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
+ __func__, ret);
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
}
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Hauke Mehrtens @ 2016-10-31 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a491509e-5cfc-fc7d-0011-dfcab3c884ea@broadcom.com>
On 10/31/2016 07:08 PM, Scott Branden wrote:
> Hi Rafal,
>
>
> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> Since early BCM5301X days we got abort handler that was removed by
>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>> fault handler"). It assumed we need to deal only with pending aborts
>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>
>> When probing PCI config space (device enumeration) it is expected to
>> have master aborts on the PCI bus. Most bridges don't forward (or they
>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>> Northstar (BCM5301X) one.
> Should we only add this workaround code if CONFIG_PCI is on then?
I think all the supported northstar devices have a PCIe controller. We
could add such a CONFIG_PCI check, but I do not see a big advantage.
>> iProc PCIe controller on Northstar seems to be some older one, without
>> a control register for errors forwarding. It means we need to workaround
>> this at platform level. All newer platforms are not affected by this
>> issue.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>> arch/arm/mach-bcm/bcm_5301x.c | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm/bcm_5301x.c
>> b/arch/arm/mach-bcm/bcm_5301x.c
>> index c8830a2..fe067f6 100644
>> --- a/arch/arm/mach-bcm/bcm_5301x.c
>> +++ b/arch/arm/mach-bcm/bcm_5301x.c
>> @@ -9,14 +9,42 @@
>> #include <asm/hardware/cache-l2x0.h>
>>
>> #include <asm/mach/arch.h>
>> +#include <asm/siginfo.h>
>> +#include <asm/signal.h>
>> +
>> +#define FSR_EXTERNAL (1 << 12)
>> +#define FSR_READ (0 << 10)
>> +#define FSR_IMPRECISE 0x0406
>>
>> static const char *const bcm5301x_dt_compat[] __initconst = {
>> "brcm,bcm4708",
>> NULL,
>> };
>>
>> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
>> + struct pt_regs *regs)
>> +{
>> + /*
>> + * We want to ignore aborts forwarded from the PCIe bus that are
>> + * expected and shouldn't really be passed by the PCIe controller.
>> + * The biggest disadvantage is the same FSR code may be reported
>> when
>> + * reading non-existing APB register and we shouldn't ignore that.
>> + */
>> + if (fsr == (FSR_EXTERNAL | FSR_READ | FSR_IMPRECISE))
>> + return 0;
How often does this happen? Would it be useful to add a log message here?
>> +
>> + return 1;
>> +}
>> +
>> +static void __init bcm5301x_init_early(void)
>> +{
>> + hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
>> + "imprecise external abort");
>> +}
>> +
>> DT_MACHINE_START(BCM5301X, "BCM5301X")
>> .l2c_aux_val = 0,
>> .l2c_aux_mask = ~0,
>> .dt_compat = bcm5301x_dt_compat,
>> + .init_early = bcm5301x_init_early,
>> MACHINE_END
>>
>
> Regards,
> Scott
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e252703-0010-83ae-fa14-57352add007a@hauke-m.de>
On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>
>
> On 10/31/2016 07:08 PM, Scott Branden wrote:
>> Hi Rafal,
>>
>>
>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> Since early BCM5301X days we got abort handler that was removed by
>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>> fault handler"). It assumed we need to deal only with pending aborts
>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>
>>> When probing PCI config space (device enumeration) it is expected to
>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>> Northstar (BCM5301X) one.
>> Should we only add this workaround code if CONFIG_PCI is on then?
>
> I think all the supported northstar devices have a PCIe controller. We
> could add such a CONFIG_PCI check, but I do not see a big advantage.
Actually, I do see a couple disadvantages if we gate this with
CONFIG_PCI: if this problem shows up irrespective of your kernel
configuration, you want the error handler to clear it, not rely on
CONFIG_PCI to be enabled for the error to go away and also, without an
additional ifdef, additional compiler coverage.
--
Florian
^ permalink raw reply
* [PATCH v2] staging: vc04_services: setup DMA and coherent mask
From: Michael Zoran @ 2016-10-31 21:02 UTC (permalink / raw)
To: linux-arm-kernel
VCHI messages between the CPU and firmware use 32-bit
bus addresses. Explicitly set the DMA mask and coherent
on all platforms.
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index a5afcc5..ba77fd8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -97,6 +97,15 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
int slot_mem_size, frag_mem_size;
int err, irq, i;
+ /*
+ * VCHI messages between the CPU and firmware use
+ * 32-bit bus addresses.
+ */
+ err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+
+ if (err < 0)
+ return err;
+
(void)of_property_read_u32(dev->of_node, "cache-line-size",
&g_cache_line_size);
g_fragments_size = 2 * g_cache_line_size;
--
2.10.1
^ permalink raw reply related
* [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Dave Gerlach @ 2016-10-31 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028040507.GJ10423@vireshk-i7>
On 10/27/2016 11:05 PM, Viresh Kumar wrote:
> On 27-10-16, 16:41, Dave Gerlach wrote:
>> Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
>> dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
>> OPP and cpufreq drivers, to make use of it.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> drivers/base/power/opp/of.c | 8 ++++----
>> drivers/base/power/opp/opp.h | 1 -
>> include/linux/pm_opp.h | 6 ++++++
>> 3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
>> index 5552211e6fcd..215f5a538c78 100644
>> --- a/drivers/base/power/opp/of.c
>> +++ b/drivers/base/power/opp/of.c
>> @@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
>> EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>>
>> /* Returns opp descriptor node for a device, caller must do of_node_put() */
>> -struct device_node *_of_get_opp_desc_node(struct device *dev)
>> +struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
>
> Export as well ?
>
Whoops, yes will need to do that. I'll give some time for comments on
any other patches before sending v3.
Thanks,
Dave
^ permalink raw reply
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eric Anholt @ 2016-10-31 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477363675.2298.2.camel@intel.com>
Zhang Rui <rui.zhang@intel.com> writes:
> On Mon, 2016-10-24 at 20:25 +0200, Stefan Wahren wrote:
>> >
>> > Eric Anholt <eric@anholt.net> hat am 24. Oktober 2016 um 18:38
>> > geschrieben:
>> >
>> >
>> > Stefan Wahren <stefan.wahren@i2se.com> writes:
>> >
>> > >
>> > > Hi Martin,
>> > >
>> > > Am 28.09.2016 um 23:10 schrieb Eric Anholt:
>> > > >
>> > > > kernel at martin.sperl.org writes:
>> > > >
>> > > > >
>> > > > > From: Martin Sperl <kernel@martin.sperl.org>
>> > > > >
>> > > > > Add basic thermal driver for bcm2835 SOC.
>> > > > >
>> > > > > This driver currently relies on the firmware setting up the
>> > > > > tsense HW block and does not set it up itself.
>> > > > >
>> > > > > Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> > > > > Acked-by: Eric Anholt <eric@anholt.net>
>> > > > > Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>> > > > What's the status of merging this one???I'd like to merge the
>> > > > other
>> > > > patches.
>> > > i think it's necessary to rebase the whole series. Maybe we could
>> > > get it
>> > > into 4.10.
>> > Why would it need to be rebased???The status, as far as I know, is
>> > that
>> > we're still waiting for the subsystem maintainer to respond.
>> Since at least this patch won't apply anymore, but feedback from
>> maintainer is
>> still good :-)
>>
>> Sorry for this impatience, but i'm afraid that we possibly miss 4.10.
>
> Eduardo,
>
> any comments on this patchset?
It's been a month on v7 of this patch. Can we please merge it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/4847b7b1/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: mediatek: clean up mach-mediatek/Makefile
From: Matthias Brugger @ 2016-10-31 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQbaQ38RZqgmJJW+BHOthrK5tPZ5JPPh9N9ry58YZ=kdg@mail.gmail.com>
On 10/31/2016 07:15 AM, Masahiro Yamada wrote:
> Hi Matthias,
>
>
> Can you pick up this for your next pull request?
>
Sure, pushed to v4.9-next/kconfig
Next time please don't forget to send your patches to the mediatek
mailinglist:
linux-mediatek at lists.infradead.org
This makes it easier for me to track the patches.
Thanks,
Matthias
>
>
> 2016-09-19 3:11 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> Kbuild descends into arch/arm/mach-mediatek/Makefile only when
>> CONFIG_ARCH_MEDIATEK is enabled. So, obj-$(CONFIG_ARCH_MEDIATEK)
>> is always equivalent to obj-y in this Makefile.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> arch/arm/mach-mediatek/Makefile | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
>> index 2116460..dadae67 100644
>> --- a/arch/arm/mach-mediatek/Makefile
>> +++ b/arch/arm/mach-mediatek/Makefile
>> @@ -1,4 +1,2 @@
>> -ifeq ($(CONFIG_SMP),y)
>> -obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
>> -endif
>> -obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
>> +obj-$(CONFIG_SMP) += platsmp.o
>> +obj-y += mediatek.o
>> --
>> 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 v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-10-31 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ_EiSRzmQHLP2PTfzsLF4uWgYgCiRGsSk=MHbtOC5rgXnnFpw@mail.gmail.com>
On Mon 2016-10-31 13:22:18, Matt Ranostay wrote:
> On Tue, Oct 25, 2016 at 11:47 AM, Matt Ranostay <mranostay@gmail.com> wrote:
> > On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
> >>> Pavel + Sebastian this is the patchset that need I some input on :)
> >>
> >> Better then previous one.
> >>
> >> But my version of bq27xxx_battery.c already contains this:
> >
> > This is for allowing udev rule to set the properties as well.
> > otherwise a kinda crude RUN = " echo value >
> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> Any thoughts on this?
I'd say echo value >
/sys/module/bq27xxx_battery/parameters/poll_interval .. is quite
adequate solution...?
Alternatively, convince us that something else is useful for everyone,
and we can do the right thing (poll more often when battery is nearly
empty), automatically...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/bb28809e/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb2c36cb-6f85-1a6d-160a-c50e22d6c46b@gmail.com>
On 16-10-31 02:01 PM, Florian Fainelli wrote:
> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>
>>
>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>> Hi Rafal,
>>>
>>>
>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>
>>>> Since early BCM5301X days we got abort handler that was removed by
>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>
>>>> When probing PCI config space (device enumeration) it is expected to
>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>> Northstar (BCM5301X) one.
>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>
>> I think all the supported northstar devices have a PCIe controller. We
>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>
> Actually, I do see a couple disadvantages if we gate this with
> CONFIG_PCI: if this problem shows up irrespective of your kernel
> configuration, you want the error handler to clear it, not rely on
> CONFIG_PCI to be enabled for the error to go away and also, without an
> additional ifdef, additional compiler coverage.
>
A problem with reintroducing this change is that all imprecise data
aborts are ignored, not just PCI. So if you don't actually use PCI in
your system and want to debug other aborts you are unable to. I don't
know if we care about such situation.
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Bjorn Helgaas @ 2016-10-31 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921223805.21652-1-cov@codeaurora.org>
On Wed, Sep 21, 2016 at 06:38:05PM -0400, Christopher Covington wrote:
> The Qualcomm Technologies QDF2432 SoC does not support accesses smaller
> than 32 bits to the PCI configuration space. Register the appropriate
> quirk.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
Hi Christopher,
Can you rebase this against v4.9-rc1? It no longer applies to my tree.
Note that this hardware is not spec-compliant since it doesn't support
sub-32 bit config writes. I just proposed a patch to warn about that
[1], so if/when we merge that patch and this one, you'll start seeing
those warnings.
[1] http://lkml.kernel.org/r/20161031213902.6340.96123.stgit at bhelgaas-glaptop.roam.corp.google.com
> ---
> drivers/acpi/pci_mcfg.c | 8 ++++++++
> drivers/pci/ecam.c | 10 ++++++++++
> include/linux/pci-ecam.h | 1 +
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 245b79f..212334f 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -96,6 +96,14 @@ static struct mcfg_fixup mcfg_quirks[] = {
> THUNDER_ECAM_MCFG(2, 12),
> THUNDER_ECAM_MCFG(2, 13),
> #endif
> + { "QCOM ", "QDF2432 ", 1, 0, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 1, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 2, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 3, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 4, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> + { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> };
>
> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
> index 43ed08d..c3b3063 100644
> --- a/drivers/pci/ecam.c
> +++ b/drivers/pci/ecam.c
> @@ -162,3 +162,13 @@ struct pci_ecam_ops pci_generic_ecam_ops = {
> .write = pci_generic_config_write,
> }
> };
> +
> +/* ops for 32 bit config space access quirk */
> +struct pci_ecam_ops pci_32b_ops = {
> + .bus_shift = 20,
> + .pci_ops = {
> + .map_bus = pci_ecam_map_bus,
> + .read = pci_generic_config_read32,
> + .write = pci_generic_config_write32,
> + }
> +};
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index 35f0e81..a6cffb8 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -65,6 +65,7 @@ extern struct pci_ecam_ops pci_thunder_pem_ops;
> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> extern struct pci_ecam_ops pci_thunder_ecam_ops;
> #endif
> +extern struct pci_ecam_ops pci_32b_ops;
>
> #ifdef CONFIG_PCI_HOST_GENERIC
> /* for DT-based PCI controllers that support ECAM */
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
> Forum, a Linux Foundation Collaborative Project.
>
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Florian Fainelli @ 2016-10-31 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dcb21fe4-672f-4545-5b47-d764f390e741@broadcom.com>
On 10/31/2016 02:46 PM, Scott Branden wrote:
>
>
> On 16-10-31 02:01 PM, Florian Fainelli wrote:
>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote:
>>>
>>>
>>> On 10/31/2016 07:08 PM, Scott Branden wrote:
>>>> Hi Rafal,
>>>>
>>>>
>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
>>>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>>>
>>>>> Since early BCM5301X days we got abort handler that was removed by
>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise
>>>>> abort
>>>>> fault handler"). It assumed we need to deal only with pending aborts
>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>>>>>
>>>>> When probing PCI config space (device enumeration) it is expected to
>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they
>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the
>>>>> Northstar (BCM5301X) one.
>>>> Should we only add this workaround code if CONFIG_PCI is on then?
>>>
>>> I think all the supported northstar devices have a PCIe controller. We
>>> could add such a CONFIG_PCI check, but I do not see a big advantage.
>>
>> Actually, I do see a couple disadvantages if we gate this with
>> CONFIG_PCI: if this problem shows up irrespective of your kernel
>> configuration, you want the error handler to clear it, not rely on
>> CONFIG_PCI to be enabled for the error to go away and also, without an
>> additional ifdef, additional compiler coverage.
>>
> A problem with reintroducing this change is that all imprecise data
> aborts are ignored, not just PCI. So if you don't actually use PCI in
> your system and want to debug other aborts you are unable to. I don't
> know if we care about such situation.
Considering that any abort is pretty much fatal, the options are:
- update the freaking bootloader to a version where there are no such
aborts generated, not an option on consumer devices, unclear which
version (if any) fixes that
- fixups the aborts externally, via a boot wrapper, which is going to
take some time to develop, causes additional burden on the distributors
to provide instructions/build images on how to do it
- fixups the aborts in the kernel, irrespective of where they come from,
simple and easy
- fixups the aborts in the kernel, look where they come from, by using
some bit of magic, looking at PCIe registers and whatnot (provided that
is even possible), not too hard, but can take a while, and is error prone
I can certainly advocate that option 3 is the one that gives a working
device, and this is what matters from a distribution perspective like
LEDE/OpenWrt.
--
Florian
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Rafał Miłecki @ 2016-10-31 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com>
On 31 October 2016 at 22:56, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 10/31/2016 02:46 PM, Scott Branden wrote:
>> A problem with reintroducing this change is that all imprecise data
>> aborts are ignored, not just PCI. So if you don't actually use PCI in
>> your system and want to debug other aborts you are unable to. I don't
>> know if we care about such situation.
>
> Considering that any abort is pretty much fatal, the options are:
>
> - update the freaking bootloader to a version where there are no such
> aborts generated, not an option on consumer devices, unclear which
> version (if any) fixes that
>
> - fixups the aborts externally, via a boot wrapper, which is going to
> take some time to develop, causes additional burden on the distributors
> to provide instructions/build images on how to do it
In practice updating bootloader is not possible (as you noticed) but I
don't think it's even possible to fix this problem at bootloader /
extra loader level. If this was a matter of hardware setup, we could
handle it in kernel as well I believe. Ray actually verified it's
controller limitation on Northstar platform.
It sounds a bit like you're thinking about MMU and Dcache Northstar
problem when writing that e-mail.
> - fixups the aborts in the kernel, irrespective of where they come from,
> simple and easy
>
> - fixups the aborts in the kernel, look where they come from, by using
> some bit of magic, looking at PCIe registers and whatnot (provided that
> is even possible), not too hard, but can take a while, and is error prone
>
> I can certainly advocate that option 3 is the one that gives a working
> device, and this is what matters from a distribution perspective like
> LEDE/OpenWrt.
--
Rafa?
^ 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