* [PATCH 1/2] PCI: save and restore device state during bus reset
From: Bjorn Helgaas @ 2016-09-13 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472770801-30671-1-git-send-email-okaya@codeaurora.org>
On Thu, Sep 01, 2016 at 07:00:00PM -0400, Sinan Kaya wrote:
> A secondary bus reset causes settings to be lost by all downstream
> devices on the tree. The code is currently saving and restoring device
> states only when called from the VFIO path via pci_probe_reset_bus
> and pci_reset_bus functions.
>
> Moving the save and restore into pci_reset_bridge_secondary_bus
> so that all users of the API have the same behavior.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/pci/pci.c | 36 +++++++++++++++---------------------
> 1 file changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index aab9d51..b209378 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3860,19 +3860,6 @@ void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
> pci_reset_secondary_bus(dev);
> }
>
> -/**
> - * pci_reset_bridge_secondary_bus - Reset the secondary bus on a PCI bridge.
> - * @dev: Bridge device
> - *
> - * Use the bridge control register to assert reset on the secondary bus.
> - * Devices on the secondary bus are left in power-on state.
> - */
> -void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
> -{
> - pcibios_reset_secondary_bus(dev);
> -}
> -EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
> -
> static int pci_parent_bus_reset(struct pci_dev *dev, int probe)
> {
> struct pci_dev *pdev;
> @@ -4362,6 +4349,21 @@ static void pci_slot_restore(struct pci_slot *slot)
> }
> }
>
> +/**
> + * pci_reset_bridge_secondary_bus - Reset the secondary bus on a PCI bridge.
> + * @dev: Bridge device
> + *
> + * Use the bridge control register to assert reset on the secondary bus.
> + * Devices on the secondary bus are left in power-on state.
> + */
> +void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
> +{
> + pci_bus_save_and_disable(dev->bus);
> + pcibios_reset_secondary_bus(dev);
> + pci_bus_restore(dev->bus);
This path eventually writes the Bridge Control register:
pci_reset_bridge_secondary_bus
pcibios_reset_secondary_bus
pci_reset_secondary_bus
pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl)
But I think it'd be easy to call this on a non-bridge device, and I
don't think there's anything in the path that checks whether this is
actually a bridge. I wonder if we should check that somewhere, or
maybe even change the interface so it takes a struct pci_bus instead
of a pci_dev.
> +}
> +EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
> +
> static int pci_slot_reset(struct pci_slot *slot, int probe)
> {
> int rc;
> @@ -4504,12 +4506,8 @@ int pci_reset_bus(struct pci_bus *bus)
> if (rc)
> return rc;
>
> - pci_bus_save_and_disable(bus);
> -
> rc = pci_bus_reset(bus, 0);
>
> - pci_bus_restore(bus);
> -
> return rc;
> }
> EXPORT_SYMBOL_GPL(pci_reset_bus);
> @@ -4528,8 +4526,6 @@ int pci_try_reset_bus(struct pci_bus *bus)
> if (rc)
> return rc;
>
> - pci_bus_save_and_disable(bus);
> -
> if (pci_bus_trylock(bus)) {
> might_sleep();
> pci_reset_bridge_secondary_bus(bus->self);
> @@ -4537,8 +4533,6 @@ int pci_try_reset_bus(struct pci_bus *bus)
> } else
> rc = -EAGAIN;
>
> - pci_bus_restore(bus);
> -
> return rc;
> }
> EXPORT_SYMBOL_GPL(pci_try_reset_bus);
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 2/2] PCI: add CRS support to error handling path
From: Bjorn Helgaas @ 2016-09-13 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd6d9d71-1ba0-84c8-7cab-21fe8b555f1c@codeaurora.org>
On Tue, Sep 13, 2016 at 05:04:49PM -0400, Sinan Kaya wrote:
> On 9/13/2016 4:01 PM, Bjorn Helgaas wrote:
> > On Thu, Sep 01, 2016 at 07:00:01PM -0400, Sinan Kaya wrote:
> >> The PCIE spec allows an endpoint device to extend the initialization time
> >> beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
> >> vendor ID read request.
> >>
> >> This basically means "I'm busy now, please call me back later".
> >>
> >> There are two moving parts to CRS support from the SW perspective. One part
> >> is to determine if CRS is supported or not. The second part is to set the
> >> CRS visibility register.
> >>
> >> As part of the probe, the Linux kernel sets the above two conditions in
> >> pci_enable_crs function. The kernel is also honoring the returned CRS in
> >> pci_bus_read_dev_vendor_id function if supported. The function will poll up
> >> to specified amount of time while endpoint is returning CRS response.
> >>
> >> The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
> >> resets.
> >>
> >> The hot reset is initiated by starting a secondary bus reset. This patch is
> >> adding vendor ID read immediately after a bus reset so that the
> >> initialization procedure can be extended by the amount of time endpoint
> >> requires.
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> drivers/pci/pci.c | 39 +++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 39 insertions(+)
> >>
> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> index b209378..ebd0fc6 100644
> >> --- a/drivers/pci/pci.c
> >> +++ b/drivers/pci/pci.c
> >> @@ -3829,6 +3829,44 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
> >> return 0;
> >> }
> >>
> >> +/*
> >> + * Mostly copy paste from pci_walk_bus with the exceptions of hard coded
> >> + * work and removed locks.
> >> + */
> >> +static void pci_bus_probe_crs(struct pci_bus *top)
> >> +{
> >> + struct pci_dev *dev;
> >> + struct pci_bus *bus;
> >> + struct list_head *next;
> >> + int retval;
> >> + u32 l;
> >> +
> >> + bus = top;
> >> + next = top->devices.next;
> >> + for (;;) {
> >> + if (next == &bus->devices) {
> >> + /* end of this bus, go up or finish */
> >> + if (bus == top)
> >> + break;
> >> + next = bus->self->bus_list.next;
> >> + bus = bus->self->bus;
> >> + continue;
> >> + }
> >> + dev = list_entry(next, struct pci_dev, bus_list);
> >> + if (dev->subordinate) {
> >> + /* this is a pci-pci bridge, do its devices next */
> >> + next = dev->subordinate->devices.next;
> >> + bus = dev->subordinate;
> >> + } else
> >> + next = dev->bus_list.next;
> >> +
> >> + retval = pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &l,
> >> + 60 * 1000);
> >> + if (retval)
> >> + break;
> >> + }
> >> +}
> >
> > Sigh. Man, this is ugly. Maybe we're locked into the current
> > strategy and don't really have a choice, but I really don't like it.
>
> I can add a locked version of the walkbus API.
> Then, I can minimize this code to a couple of lines. How does that sound?
I didn't mean that, I meant the whole idea of having to walk the whole
hierarchy and touch each device. It's sort of like we're enumerating
things, but not really, so this checking is kinda sorta parallel to
the enumeration path.
> > You mentioned several kinds of reset where CRS is allowed. Doesn't this
> > fix only one of them? I know we support at least FLR reset also.
>
> The CRS is for hot reset, warm reset and FLR reset. There is nothing we can do in SW
> for warm reset. This patch is to address hot reset caused by SBR.
>
> I was hoping that Alex would help us for directions on the FLR reset later.
What sort of help from Alex were you hoping for? Is fixing the FLR
path harder than this one? If we're going to fix one path, I'd prefer
to fix them all at the same time rather than tripping over this again
later.
^ permalink raw reply
* [PATCH 2/2] PCI: add CRS support to error handling path
From: Sinan Kaya @ 2016-09-13 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913200152.GE4138@localhost>
On 9/13/2016 4:01 PM, Bjorn Helgaas wrote:
> On Thu, Sep 01, 2016 at 07:00:01PM -0400, Sinan Kaya wrote:
>> The PCIE spec allows an endpoint device to extend the initialization time
>> beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
>> vendor ID read request.
>>
>> This basically means "I'm busy now, please call me back later".
>>
>> There are two moving parts to CRS support from the SW perspective. One part
>> is to determine if CRS is supported or not. The second part is to set the
>> CRS visibility register.
>>
>> As part of the probe, the Linux kernel sets the above two conditions in
>> pci_enable_crs function. The kernel is also honoring the returned CRS in
>> pci_bus_read_dev_vendor_id function if supported. The function will poll up
>> to specified amount of time while endpoint is returning CRS response.
>>
>> The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
>> resets.
>>
>> The hot reset is initiated by starting a secondary bus reset. This patch is
>> adding vendor ID read immediately after a bus reset so that the
>> initialization procedure can be extended by the amount of time endpoint
>> requires.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> drivers/pci/pci.c | 39 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b209378..ebd0fc6 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3829,6 +3829,44 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
>> return 0;
>> }
>>
>> +/*
>> + * Mostly copy paste from pci_walk_bus with the exceptions of hard coded
>> + * work and removed locks.
>> + */
>> +static void pci_bus_probe_crs(struct pci_bus *top)
>> +{
>> + struct pci_dev *dev;
>> + struct pci_bus *bus;
>> + struct list_head *next;
>> + int retval;
>> + u32 l;
>> +
>> + bus = top;
>> + next = top->devices.next;
>> + for (;;) {
>> + if (next == &bus->devices) {
>> + /* end of this bus, go up or finish */
>> + if (bus == top)
>> + break;
>> + next = bus->self->bus_list.next;
>> + bus = bus->self->bus;
>> + continue;
>> + }
>> + dev = list_entry(next, struct pci_dev, bus_list);
>> + if (dev->subordinate) {
>> + /* this is a pci-pci bridge, do its devices next */
>> + next = dev->subordinate->devices.next;
>> + bus = dev->subordinate;
>> + } else
>> + next = dev->bus_list.next;
>> +
>> + retval = pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &l,
>> + 60 * 1000);
>> + if (retval)
>> + break;
>> + }
>> +}
>
> Sigh. Man, this is ugly. Maybe we're locked into the current
> strategy and don't really have a choice, but I really don't like it.
I can add a locked version of the walkbus API.
Then, I can minimize this code to a couple of lines. How does that sound?
>
>> +
>> void pci_reset_secondary_bus(struct pci_dev *dev)
>> {
>> u16 ctrl;
>> @@ -4361,6 +4399,7 @@ void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
>> pci_bus_save_and_disable(dev->bus);
>> pcibios_reset_secondary_bus(dev);
>> pci_bus_restore(dev->bus);
>> + pci_bus_probe_crs(dev->subordinate);
>
> This looks backwards -- pci_bus_restore() uses config accesses, so surely
> you want to do the CRS check *before* that, right? Oh, never mind, I see
> you already caught this.
Yep, I was waiting for your feedback before re-posting.
>
> You mentioned several kinds of reset where CRS is allowed. Doesn't this
> fix only one of them? I know we support at least FLR reset also.
The CRS is for hot reset, warm reset and FLR reset. There is nothing we can do in SW
for warm reset. This patch is to address hot reset caused by SBR.
I was hoping that Alex would help us for directions on the FLR reset later.
>
>> }
>> EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
>>
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
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] Documentation: dt-bindings: Fix "st,syscfg" definition for STM32 pinctrl
From: Linus Walleij @ 2016-09-13 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473773292-10225-1-git-send-email-alexandre.torgue@st.com>
On Tue, Sep 13, 2016 at 3:28 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> "st,syscfg" entry was bad described.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 4/7] palmetto: Request relevant mux functions in devicetree
From: Benjamin Herrenschmidt @ 2016-09-13 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xe-dowcwXkO8rDH2reMzGadUMSq5ZtV=23FP4virt+DUQ@mail.gmail.com>
On Tue, 2016-09-13 at 22:11 +0930, Joel Stanley wrote:
> It's not clear that all systems use these pins in that way. I will
> not
> include this one for now.
Well, it has VGA so the VGA hsync, vsync and DDC should be there at
least...
Ben.
^ permalink raw reply
* [PATCH v3 3/7] arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1
From: Kees Cook @ 2016-09-13 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-4-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 10:46 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> This patch adds the uaccess macros/functions to disable access to user
> space by setting TTBR0_EL1 to a reserved zeroed page. Since the value
> written to TTBR0_EL1 must be a physical address, for simplicity this
> patch introduces a reserved_ttbr0 page at a constant offset from
> swapper_pg_dir. The uaccess_disable code uses the ttbr1_el1 value
> adjusted by the reserved_ttbr0 offset.
>
> Enabling access to user is done by restoring TTBR0_EL1 with the value
> from the struct thread_info ttbr0 variable. Interrupts must be disabled
> during the uaccess_ttbr0_enable code to ensure the atomicity of the
> thread_info.ttbr0 read and TTBR0_EL1 write. This patch also moves the
> get_thread_info asm macro from entry.S to assembler.h for reuse in the
> uaccess_ttbr0_* macros.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> [...]
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 7099f26e3702..042d49c7b231 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -216,6 +216,12 @@ static inline bool system_supports_mixed_endian_el0(void)
> return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
> }
>
> +static inline bool system_uses_ttbr0_pan(void)
> +{
> + return IS_ENABLED(CONFIG_ARM64_SW_TTBR0_PAN) &&
> + !cpus_have_cap(ARM64_HAS_PAN);
> +}
> +
> #endif /* __ASSEMBLY__ */
>
> #endif
> [...]
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index cc6c32d4dcc4..115b5fa8dc3f 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> [...]
> @@ -116,16 +117,57 @@ static inline void set_fs(mm_segment_t fs)
> [...]
> #define __uaccess_disable(alt) \
> do { \
> - asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt, \
> - CONFIG_ARM64_PAN)); \
> + if (system_uses_ttbr0_pan()) \
> + uaccess_ttbr0_disable(); \
> + else \
> + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt, \
> + CONFIG_ARM64_PAN)); \
> } while (0)
>
> #define __uaccess_enable(alt) \
> do { \
> - asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> - CONFIG_ARM64_PAN)); \
> + if (system_uses_ttbr0_pan()) \
> + uaccess_ttbr0_enable(); \
> + else \
> + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> + CONFIG_ARM64_PAN)); \
> } while (0)
Does this mean that with CONFIG_ARM64_SW_TTBR0_PAN, even with ARMv8.1,
a cpu capability bitmask check is done each time we go through
__uaccess_{en,dis}able?
Could the alternative get moved around slightly to avoid this, or am I
misunderstanding something here?
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-09-13 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913070358.GB30425@b29397-desktop>
Quoting Peter Chen (2016-09-13 00:03:58)
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > The high-speed phy on qcom SoCs is controlled via the ULPI
> > viewport.
> >
>
> Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> before access portsc.pts (calling hw_phymode_configure), otherwise,
> the system will hang. But I find you call hw_phymode_configure before
> phy->power_on, doesn't your design have this requirement?
Which clk needs to be enabled? The xcvr_clk? I believe that clk
corresponds to the "core" clk that we enable in the msm glue driver
layer. When that clk is enabled, the ULPI phy is able to respond to
register read/writes via the ULPI viewport.
>
> Besides, you read ulpi id before phy->power_on, how can read work before
> phy power on?
>
I've found that even having the link clk enabled before phy->power_on
doesn't mean it's possible to read the id registers though. That's
because there can be other power supplies, like regulators, which need
to be on for the phy to operate properly.
Either way, the system does not hang.
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Arnd Bergmann @ 2016-09-13 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r38nehkj.fsf@free-electrons.com>
On Tuesday, September 13, 2016 9:16:28 PM CEST Gregory CLEMENT wrote:
> Hi Jamie,
>
> On mar., sept. 13 2016, Jamie Lentin <jm@lentin.co.uk> wrote:
>
> > On 2016-09-13 13:36, Andrew Lunn wrote:
> >> On Tue, Sep 13, 2016 at 10:10:41AM +0100, Jamie Lentin wrote:
> >>> On 2016-09-12 23:03, Andrew Lunn wrote:
> >>> >>Maybe we can instead leave out the PCI support from the new
> >>> >>file for now and not delete the legacy board file?
> >>>
> >>> This seems a reasonable compromise. The PCI card the router comes
> >>> with isn't supported by mwl8k mainline anyway (There's STA-only
> >>> firmware that can be extracted from a windows driver and PCI IDs
> >>> added, but stats reporting uses a different format), so it's not a
> >>> huge loss, although many did replace the card with something
> >>> Atheros-based.
> >>
> >> O.K. So dropping the PCI code gets us going forward.
> >
> > Is an arch/arm/mach-mvebu/orion5x.c also required? Or is continuing to
> > use arch/arm/mach-orion5x/board-dt.c until everything has been
> > converted the favoured approach?
> >
> >> Have we missed the merge window?
> >
> > I got the impression Gregory Clement had merged them? If not a good
> > portion of this patchset is uncontroversial generic orion5x stuff,
> > it'd be nice to get those in even if none of the router-specific stuff
> > doesn't make it.
>
> I applied on mvebu/for-next in order to find any merge conflict. It
> seems ok on this side. However, I didn't make the pull request to
> arm-soc with these patches so I fear it is too late.
>
> Arnd would you agree to accept a new pull request?
Yes, please just send it. We are a bit backlogged on pull requests,
but because you got all the other pull requests to us early, you can
always have a couple of late changes on top that we would normally
pull.
Arnd
^ permalink raw reply
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Ard Biesheuvel @ 2016-09-13 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913202410.GA2947@remoulade>
On 13 September 2016 at 21:24, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Sep 13, 2016 at 08:18:52PM +0100, Ard Biesheuvel wrote:
>> On 13 September 2016 at 18:35, Mark Rutland <mark.rutland@arm.com> wrote:
>> Thanks. But actually, I think it makes sense to make the first
>> swapper_pg_dir page read-only as well, given that it is only modified
>> via the fixmap, and we can trivially extend the r/o bss region to end
>> at 'swapper_pg_dir + PAGE_SIZE'
>>
>> Thoughts?
>
> I thought that we lazy-allocated the vmalloc region at runtime, and initialised
> pgd level entries.
>
> From a quick dig it looks like a vmalloc() could eventually call
> pgd_populate(), which seems to set a pgd entry without using a fixmap slot.
>
> Is there some reason that won't happen at runtime?
>
Ah, right. I thought all swapper_pg_dir manipulations went via the
arch64/mm/mmu.c routines that use the fixmap slots, but apparently
this is not the case.
^ permalink raw reply
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-09-13 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu90AokunA3zOcNhwXsFpCpoY_juipnr3y68nefZk9Ff0w@mail.gmail.com>
On Tue, Sep 13, 2016 at 08:18:52PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 18:35, Mark Rutland <mark.rutland@arm.com> wrote:
> Thanks. But actually, I think it makes sense to make the first
> swapper_pg_dir page read-only as well, given that it is only modified
> via the fixmap, and we can trivially extend the r/o bss region to end
> at 'swapper_pg_dir + PAGE_SIZE'
>
> Thoughts?
I thought that we lazy-allocated the vmalloc region at runtime, and initialised
pgd level entries.
>From a quick dig it looks like a vmalloc() could eventually call
pgd_populate(), which seems to set a pgd entry without using a fixmap slot.
Is there some reason that won't happen at runtime?
Thanks,
Mark.
^ permalink raw reply
* [RESEND][PATCH V7 0/5] perf: Driver specific configuration for PMU
From: Arnaldo Carvalho de Melo @ 2016-09-13 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473179837-3293-1-git-send-email-mathieu.poirier@linaro.org>
Em Tue, Sep 06, 2016 at 10:37:12AM -0600, Mathieu Poirier escreveu:
> Original blurb:
> ---------------
So, I managed to apply "perf tools: add infrastructure for PMU specific
configuration", the first, as we discussed, needs splitting, some don't
apply due to the first not being applied, and one fails 'perf test
python', which I'll look at tomorrow.
- Arnaldo
> This patchset adds the possiblity of specifying PMU driver configuration
> directly from the perf command line. Anything that falls within the
> event specifiers '/.../' and that is preceded by the '@' symbol is
> treated as a configurable. Two formats are supported, @cfg and
> @cfg=config.
>
> For example:
>
> perf record -e some_event/@cfg1/ ...
>
> or
>
> perf record -e some_event/@cfg2=config/ ...
>
> or
>
> perf record -e some_event/@cfg1, at cfg2=config/ ...
>
> The above are all valid configuration and will see the strings 'cfg1'
> and 'cfg2=config' sent to the PMU driver for parsing and interpretation
> using the existing ioctl() mechanism.
>
> The primary customers for this feature are the CoreSight drivers where
> the selection of a sink (where trace data is accumulated) needs to be
> done in a previous, and separated step, from the launching of the perf
> command.
>
> As such something that used to be a two-step process:
>
> # echo 1 > /sys/bus/coresight/devices/20070000.etr/enable_sink
> # perf record -e cs_etm//u --per-thread uname
>
> is integrated in a single command:
>
> # perf record -e cs_etm/@20070000.etr/u --per-thread uname
>
> Thanks,
> Mathieu
>
> Changes for V7:
> - Got rid of a miscellaneous debug message.
> - Rebased to v4.8-rc4
> - Added Jiri Olsa's Acked-by.
>
> Changes for V6:
> - Using sysFS rather than an ioctl() to communicate command line
> parameters to the CoreSight PMU.
>
> Changes for V5:
> - Made commit log in 5/9 more descriptive.
> - Addressed missing return code in builtin-top.c.
> - Overhauled the kernel portion to do parsing in the core.
>
> Changes for V4:
> - Pushing PMU driver configuration for 'perf top'.
> - Rebased to the latest perf/core branch[1].
>
> Changes for V3:
> - Added comment for function drv_str() that explains the reason for
> keeping the entire token intact.
> - Added driver config terms to the existing list of config terms.
> - Added documenation for driver specific configuration.
> - Pushing PMU driver configuration for 'perf stat' as well.
> - Preventing users from selecting a sink from sysFS _and_ perf.
>
> Changes for V2:
> - Rebased to [1] as per Jiri's request.
>
>
> Mathieu Poirier (5):
> perf tools: making coresight PMU listable
> perf tools: adding coresight etm PMU record capabilities
> perf tools: add infrastructure for PMU specific configuration
> perf tools: Pushing configuration down to PMU driver
> perf tools: adding sink configuration for cs_etm PMU
>
> MAINTAINERS | 5 +
> tools/perf/Documentation/perf-record.txt | 12 +
> tools/perf/Makefile.config | 11 +-
> tools/perf/arch/arm/util/Build | 2 +
> tools/perf/arch/arm/util/auxtrace.c | 54 +++
> tools/perf/arch/arm/util/cs-etm.c | 615 +++++++++++++++++++++++++++++++
> tools/perf/arch/arm/util/cs-etm.h | 26 ++
> tools/perf/arch/arm/util/pmu.c | 37 ++
> tools/perf/arch/arm64/util/Build | 4 +
> tools/perf/builtin-record.c | 9 +
> tools/perf/builtin-stat.c | 8 +
> tools/perf/builtin-top.c | 12 +
> tools/perf/util/auxtrace.c | 1 +
> tools/perf/util/auxtrace.h | 1 +
> tools/perf/util/cs-etm.h | 74 ++++
> tools/perf/util/evlist.c | 18 +
> tools/perf/util/evlist.h | 3 +
> tools/perf/util/evsel.c | 40 ++
> tools/perf/util/evsel.h | 4 +
> tools/perf/util/parse-events.c | 7 +-
> tools/perf/util/parse-events.h | 1 +
> tools/perf/util/parse-events.l | 22 ++
> tools/perf/util/parse-events.y | 11 +
> tools/perf/util/pmu.h | 2 +
> 24 files changed, 974 insertions(+), 5 deletions(-)
> create mode 100644 tools/perf/arch/arm/util/auxtrace.c
> create mode 100644 tools/perf/arch/arm/util/cs-etm.c
> create mode 100644 tools/perf/arch/arm/util/cs-etm.h
> create mode 100644 tools/perf/arch/arm/util/pmu.c
> create mode 100644 tools/perf/util/cs-etm.h
>
> --
> 2.7.4
^ permalink raw reply
* [PATCH 2/2] PCI: add CRS support to error handling path
From: Bjorn Helgaas @ 2016-09-13 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472770801-30671-2-git-send-email-okaya@codeaurora.org>
On Thu, Sep 01, 2016 at 07:00:01PM -0400, Sinan Kaya wrote:
> The PCIE spec allows an endpoint device to extend the initialization time
> beyond 1 second by issuing Configuration Request Retry Status (CRS) for a
> vendor ID read request.
>
> This basically means "I'm busy now, please call me back later".
>
> There are two moving parts to CRS support from the SW perspective. One part
> is to determine if CRS is supported or not. The second part is to set the
> CRS visibility register.
>
> As part of the probe, the Linux kernel sets the above two conditions in
> pci_enable_crs function. The kernel is also honoring the returned CRS in
> pci_bus_read_dev_vendor_id function if supported. The function will poll up
> to specified amount of time while endpoint is returning CRS response.
>
> The PCIe spec also allows CRS to be issued during cold, warm, hot and FLR
> resets.
>
> The hot reset is initiated by starting a secondary bus reset. This patch is
> adding vendor ID read immediately after a bus reset so that the
> initialization procedure can be extended by the amount of time endpoint
> requires.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/pci/pci.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b209378..ebd0fc6 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3829,6 +3829,44 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
> return 0;
> }
>
> +/*
> + * Mostly copy paste from pci_walk_bus with the exceptions of hard coded
> + * work and removed locks.
> + */
> +static void pci_bus_probe_crs(struct pci_bus *top)
> +{
> + struct pci_dev *dev;
> + struct pci_bus *bus;
> + struct list_head *next;
> + int retval;
> + u32 l;
> +
> + bus = top;
> + next = top->devices.next;
> + for (;;) {
> + if (next == &bus->devices) {
> + /* end of this bus, go up or finish */
> + if (bus == top)
> + break;
> + next = bus->self->bus_list.next;
> + bus = bus->self->bus;
> + continue;
> + }
> + dev = list_entry(next, struct pci_dev, bus_list);
> + if (dev->subordinate) {
> + /* this is a pci-pci bridge, do its devices next */
> + next = dev->subordinate->devices.next;
> + bus = dev->subordinate;
> + } else
> + next = dev->bus_list.next;
> +
> + retval = pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &l,
> + 60 * 1000);
> + if (retval)
> + break;
> + }
> +}
Sigh. Man, this is ugly. Maybe we're locked into the current
strategy and don't really have a choice, but I really don't like it.
> +
> void pci_reset_secondary_bus(struct pci_dev *dev)
> {
> u16 ctrl;
> @@ -4361,6 +4399,7 @@ void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
> pci_bus_save_and_disable(dev->bus);
> pcibios_reset_secondary_bus(dev);
> pci_bus_restore(dev->bus);
> + pci_bus_probe_crs(dev->subordinate);
This looks backwards -- pci_bus_restore() uses config accesses, so surely
you want to do the CRS check *before* that, right? Oh, never mind, I see
you already caught this.
You mentioned several kinds of reset where CRS is allowed. Doesn't this
fix only one of them? I know we support at least FLR reset also.
> }
> EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [arm:sa1100 80/81] arch/arm/mach-pxa/mainstone.c:560: undefined reference to `gpio_reg_init'
From: Russell King - ARM Linux @ 2016-09-13 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201609140228.hC8MtpFb%fengguang.wu@intel.com>
On Wed, Sep 14, 2016 at 02:12:30AM +0800, kbuild test robot wrote:
> tree: git://git.armlinux.org.uk/~rmk/linux-arm.git sa1100
> head: 36b075e9681a293ef57aaa107ab394bc879a0807
> commit: 4c76c25bd4f755e2302807f99b75ff9954c036d1 [80/81] ARM: pxa/mainstone: convert PCMCIA to use MAX1600 driver and gpiod APIs
> config: arm-mainstone_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 4c76c25bd4f755e2302807f99b75ff9954c036d1
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
> arch/arm/mach-pxa/built-in.o: In function `mainstone_init':
> >> arch/arm/mach-pxa/mainstone.c:560: undefined reference to `gpio_reg_init'
> arch/arm/mach-pxa/mainstone.c:563: undefined reference to `gpio_reg_init'
Thanks, fixed.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: lpc18xx: add boot rom node
From: Joachim Eastwood @ 2016-09-13 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913195117.2887-1-manabian@gmail.com>
Add node for the boot ROM found on all NXP LPC18xx/43xx devices.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/boot/dts/lpc18xx.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 631e6f6c..9f94f3e 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -81,6 +81,14 @@
status = "disabled";
};
+ boot_rom: firmware at 10400000 {
+ compatible = "nxp,lpc1850-boot-rom";
+ reg = <0x10400000 0x10000>;
+ syscon = <&creg>;
+ nvmem-cells = <&part_id>;
+ nvmem-cell-names = "PartID";
+ };
+
dmac: dma-controller at 40002000 {
compatible = "arm,pl080", "arm,primecell";
arm,primecell-periphid = <0x00041080>;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] firmware: dt: document lpc1850 boot ROM bindings
From: Joachim Eastwood @ 2016-09-13 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913195117.2887-1-manabian@gmail.com>
Binding documentation for the NXP LPC boot ROM.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
.../devicetree/bindings/firmware/nxp,boot-rom.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
diff --git a/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
new file mode 100644
index 0000000..5f3a044
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
@@ -0,0 +1,21 @@
+* NXP LPC boot ROM
+
+NXP LPC microcontrollers contains a boot ROM used to retrieve part information
+and access internal Flash memory and OTP memory. Note that the Flash API is
+not available on Flashless devices.
+
+Required properties:
+- compatible: must contain the following: "nxp,lpc1850-boot-rom".
+- reg: physical base address of the ROM and length of memory mapped region.
+- syscon: handle to NXP CREG (Configuration Registers) syscon block.
+- nvmem-cells: = handle to OTP memory cell which contain the part ID.
+- nvmem-cell-names: must contain "PartID".
+
+Example:
+boot_rom: firmware at 10400000 {
+ compatible = "nxp,lpc1850-boot-rom";
+ reg = <0x10400000 0x10000>;
+ syscon = <&creg>;
+ nvmem-cells = <&part_id>;
+ nvmem-cell-names = "PartID";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] firmware: add lpc18xx boot rom driver
From: Joachim Eastwood @ 2016-09-13 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913195117.2887-1-manabian@gmail.com>
Firmware driver for the boot ROM found on all NXP LPC18xx/43xx
devices. This driver makes it possible to retrieve device specific
information from either the ROM via API calls or from OTP memory.
The boot ROM contains several APIs for on-chip devices. Note that not
all APIs are available on all devices. The API to retrieve device
information and internal Flash programming (IAP) is only available on
devices with Flash. Flashless devices retrieve device information from
OTP memory. The CHIPID register in CREG (syscon) is used to check if
IAP is available.
For now this driver is only used to expose device information via a
'SoC device'. Linux API for the IAP and OTP will be added later. These
two APIs will be used by a Flash MTD driver and a OTP NVMEM driver to
program the memory.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/firmware/Kconfig | 12 ++
drivers/firmware/Makefile | 1 +
drivers/firmware/nxp_lpc_boot_rom.c | 411 ++++++++++++++++++++++++++++++++++++
3 files changed, 424 insertions(+)
create mode 100644 drivers/firmware/nxp_lpc_boot_rom.c
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 0e22f24..904f727 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -163,6 +163,18 @@ config ISCSI_IBFT
detect iSCSI boot parameters dynamically during system boot, say Y.
Otherwise, say N.
+config NXP_LPC_BOOT_ROM
+ tristate "NXP LPC boot ROM API"
+ depends on ARCH_LPC18XX || COMPILE_TEST
+ depends on OF && HAS_IOMEM && NVMEM
+ select MFD_SYSCON
+ select SOC_BUS
+ help
+ This option enables support for using the API in the boot ROM
+ present on NXP LPC18xx and LPC43xx devices. This is required
+ to retrieve part specific information and for writing to the
+ internal Flash and OTP memories.
+
config RASPBERRYPI_FIRMWARE
tristate "Raspberry Pi Firmware Driver"
depends on BCM2835_MBOX
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 44a59dc..0060afd 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DMIID) += dmi-id.o
obj-$(CONFIG_ISCSI_IBFT_FIND) += iscsi_ibft_find.o
obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o
obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
+obj-$(CONFIG_NXP_LPC_BOOT_ROM) += nxp_lpc_boot_rom.o
obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
diff --git a/drivers/firmware/nxp_lpc_boot_rom.c b/drivers/firmware/nxp_lpc_boot_rom.c
new file mode 100644
index 0000000..825824a
--- /dev/null
+++ b/drivers/firmware/nxp_lpc_boot_rom.c
@@ -0,0 +1,411 @@
+/*
+ * Firmware driver for NXP LPC18xx/43xx boot ROM
+ *
+ * Copyright (C) 2016 Joachim Eastwood <manabian@gmail.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/err.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/random.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include <linux/sys_soc.h>
+
+/*
+ * The boot ROM on LPC18xx/43xx contain APIs to program
+ * the internal Flash and OTP memory.
+ *
+ * IAP (In-Application Programming) is used to program
+ * the internal Flash and to retrieve device specific
+ * information like part ID, ROM version and serial
+ * number. IAP is only available on Flash devices.
+ */
+
+/* IAP commands */
+#define IAP_READ_PART_ID 54
+#define IAP_BOOT_CODE_VER 55
+#define IAP_READ_SERIAL_NUMBER 58
+
+#define IAP_CMD_MAX_LEN 6
+#define IAP_RES_MAX_LEN 5
+
+/* IAP device information */
+#define IAP_BOOT_CODE_VER_MAJOR(v) ((v >> 16) & 0xff)
+#define IAP_BOOT_CODE_VER_MINOR(v) (v & 0xff)
+#define IAP_BOOT_CODE_VER_SIZE sizeof(u32)
+#define IAP_PART_ID_SIZE (sizeof(u32) * 2)
+#define IAP_SERIAL_NUMBER_SIZE (sizeof(u32) * 4)
+
+#define LPC18XX_OTP_PART_ID_SIZE (sizeof(u32) * 4)
+
+/* LPC18xx/43xx ROM addresses */
+#define LPC18XX_ROM_TABLE 0x100
+#define LPC18XX_IAP_TABLE (LPC18XX_ROM_TABLE + 0x0)
+#define LPC18XX_ROM_VERSION 0x7ffc
+
+/* LPC18xx/43xx CREG (syscon) defines */
+#define LPC18XX_CREG_CHIPID 0x200
+#define LPC18XX_FLASH_CHIPID0 0x4284e02b
+#define LPC18XX_FLASH_CHIPID1 0x7284e02b
+#define LPC18XX_FLASHLESS_CHIPID0 0x5284e02b
+#define LPC18XX_FLASHLESS_CHIPID1 0x6284e02b
+#define LPC43XX_FLASH_CHIPID0 0x4906002b
+#define LPC43XX_FLASH_CHIPID1 0x7906002b
+#define LPC43XX_FLASHLESS_CHIPID0 0x5906002b
+#define LPC43XX_FLASHLESS_CHIPID1 0x6906002b
+
+#define NXP_PART_LPC(_num, _id0, _id1, _sz0, _sz1) \
+ { \
+ .name = "LPC"#_num, \
+ .id[0] = _id0, .id[1] = _id1, \
+ .flash_size[0] = _sz0 * 1024, \
+ .flash_size[1] = _sz1 * 1024, \
+ }
+
+
+struct nxp_lpc_part {
+ const char *name;
+ u16 flash_size[2];
+ u32 id[2];
+};
+
+static const struct nxp_lpc_part nxp_lpc_parts[] = {
+ /* LPC18xx Flashless parts */
+ NXP_PART_LPC(1850, 0xf000d830, 0x00, 0, 0),
+ NXP_PART_LPC(18S50, 0xf000d860, 0x00, 0, 0),
+ NXP_PART_LPC(1830, 0xf000da30, 0x00, 0, 0),
+ NXP_PART_LPC(18S30, 0xf000da60, 0x00, 0, 0),
+ NXP_PART_LPC(1820, 0xf00adb3c, 0x00, 0, 0),
+ NXP_PART_LPC(18S20, 0xf00adb6c, 0x00, 0, 0),
+ NXP_PART_LPC(1810, 0xf00b5b3f, 0x00, 0, 0),
+ NXP_PART_LPC(18S10, 0xf00b5b6f, 0x00, 0, 0),
+ /* LPC18xx Flash parts */
+ NXP_PART_LPC(1857, 0xf001d830, 0x00, 512, 512),
+ NXP_PART_LPC(18S57, 0xf001d860, 0x00, 512, 512),
+ NXP_PART_LPC(1853, 0xf001d830, 0x44, 256, 256),
+ NXP_PART_LPC(1837, 0xf001da30, 0x00, 512, 512),
+ NXP_PART_LPC(18S37, 0xf001d860, 0x00, 512, 512),
+ NXP_PART_LPC(1833, 0xf001da30, 0x44, 256, 256),
+ NXP_PART_LPC(1827, 0xf001db3c, 0x00, 512, 512),
+ NXP_PART_LPC(1825, 0xf001db3c, 0x22, 384, 384),
+ NXP_PART_LPC(1823, 0xf00bdb3c, 0x44, 256, 256),
+ NXP_PART_LPC(1822, 0xf00bdb3c, 0x80, 512, 0),
+ NXP_PART_LPC(1817, 0xf001db3f, 0x00, 512, 512),
+ NXP_PART_LPC(1815, 0xf001db3f, 0x22, 384, 384),
+ NXP_PART_LPC(1813, 0xf00bdb3f, 0x44, 256, 256),
+ NXP_PART_LPC(1812, 0xf00bdb3f, 0x80, 512, 0),
+ /* LPC43xx Flashless parts */
+ NXP_PART_LPC(4370, 0x00000030, 0x00, 0, 0), /* LBGA256 */
+ NXP_PART_LPC(4370, 0x00000230, 0x00, 0, 0), /* TFBGA100 */
+ NXP_PART_LPC(43S70, 0x00000060, 0x00, 0, 0),
+ NXP_PART_LPC(4350, 0xa0000830, 0x00, 0, 0),
+ NXP_PART_LPC(43S50, 0xa0000860, 0x00, 0, 0),
+ NXP_PART_LPC(4330, 0xa0000a30, 0x00, 0, 0),
+ NXP_PART_LPC(43S30, 0xa0000a60, 0x00, 0, 0),
+ NXP_PART_LPC(4320, 0xa000cb3c, 0x00, 0, 0),
+ NXP_PART_LPC(43S20, 0xa000cb6c, 0x00, 0, 0),
+ NXP_PART_LPC(4310, 0xa00acb3f, 0x00, 0, 0),
+ /* LPC43xx parts with Flash */
+ NXP_PART_LPC(4367, 0x8001c030, 0x00, 512, 512),
+ NXP_PART_LPC(43S67, 0x8001c060, 0x00, 512, 512),
+ NXP_PART_LPC(4357, 0xa001c830, 0x00, 512, 512),
+ NXP_PART_LPC(43S57, 0xa001c860, 0x00, 512, 512), /* LBGA256 */
+ NXP_PART_LPC(43S57, 0xa001ca60, 0x00, 512, 512), /* LQFP208 */
+ NXP_PART_LPC(4353, 0xa001c830, 0x44, 256, 256),
+ NXP_PART_LPC(4337, 0xa001ca30, 0x00, 512, 512),
+ NXP_PART_LPC(43S37, 0xa001ca60, 0x00, 512, 512),
+ NXP_PART_LPC(4333, 0xa001ca30, 0x44, 256, 256),
+ NXP_PART_LPC(4327, 0xa001cb3c, 0x00, 512, 512),
+ NXP_PART_LPC(4325, 0xa001cb3c, 0x22, 384, 384),
+ NXP_PART_LPC(4323, 0xa00bcb3c, 0x44, 256, 256),
+ NXP_PART_LPC(4322, 0xa00bcb3c, 0x80, 512, 0),
+ NXP_PART_LPC(4317, 0xa001cb3f, 0x00, 512, 512),
+ NXP_PART_LPC(4315, 0xa001cb3f, 0x22, 384, 384),
+ NXP_PART_LPC(4313, 0xa00bcb3f, 0x44, 256, 256),
+ NXP_PART_LPC(4312, 0xa00bcb3f, 0x80, 512, 0),
+};
+
+struct iap_rom {
+ void (*entry)(u32 *, u32 *);
+};
+
+struct nxp_rom_api {
+ struct device *dev;
+ void __iomem *rom;
+
+ bool has_iap;
+ struct iap_rom iap;
+ spinlock_t lock;
+
+ const struct nxp_lpc_part *part;
+ const char *partname;
+ u32 boot_version;
+
+ struct soc_device *soc_dev;
+ struct soc_device_attribute soc_dev_attr;
+};
+
+static const struct nxp_lpc_part *nxp_lpc_boot_rom_find_part(u32 *id, bool flash)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(nxp_lpc_parts); i++) {
+ if (nxp_lpc_parts[i].id[0] == id[0]) {
+ if (!flash || ((nxp_lpc_parts[i].id[1] & 0xff) == id[1]))
+ return &nxp_lpc_parts[i];
+ }
+ }
+
+ return NULL;
+}
+
+static inline void iap_entry(struct nxp_rom_api *data, u32 *cmd, u32 *res)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&data->lock, flags);
+ data->iap.entry(cmd, res);
+ spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static int iap_read_id(struct nxp_rom_api *data, u32 *id)
+{
+ u32 command[IAP_CMD_MAX_LEN];
+ u32 result[IAP_RES_MAX_LEN];
+
+ command[0] = IAP_READ_PART_ID;
+ iap_entry(data, command, result);
+
+ id[0] = result[1];
+ id[1] = result[2];
+
+ return 0;
+}
+
+static int iap_read_boot_version(struct nxp_rom_api *data, u32 *version)
+{
+ u32 command[IAP_CMD_MAX_LEN];
+ u32 result[IAP_RES_MAX_LEN];
+
+ command[0] = IAP_BOOT_CODE_VER;
+ iap_entry(data, command, result);
+
+ *version = result[1];
+
+ return 0;
+}
+
+static int iap_read_serial_number(struct nxp_rom_api *data, u32 *serial)
+{
+ u32 command[IAP_CMD_MAX_LEN];
+ u32 result[IAP_RES_MAX_LEN];
+
+ command[0] = IAP_READ_SERIAL_NUMBER;
+ iap_entry(data, command, result);
+
+ serial[0] = result[1];
+ serial[1] = result[2];
+ serial[2] = result[3];
+ serial[3] = result[4];
+
+ return 0;
+}
+
+static int nxp_get_flashless_part_id(struct nxp_rom_api *data)
+{
+ size_t id_len = LPC18XX_OTP_PART_ID_SIZE;
+ struct nvmem_cell *cell;
+ u32 *id;
+
+ cell = of_nvmem_cell_get(data->dev->of_node, "PartID");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ id = nvmem_cell_read(cell, &id_len);
+ nvmem_cell_put(cell);
+
+ if (IS_ERR(id)) {
+ dev_err(data->dev, "unable to read part id from nvmem");
+ return PTR_ERR(id);
+ }
+
+ data->part = nxp_lpc_boot_rom_find_part(id, false);
+ if (!data->part)
+ dev_warn(data->dev, "unknown LPC part\n");
+ else
+ data->partname = data->part->name;
+
+ return 0;
+}
+
+static int nxp_lpc_boot_rom_iap_setup(struct nxp_rom_api *data)
+{
+ u32 ser[IAP_SERIAL_NUMBER_SIZE];
+ unsigned long rom_pointer;
+ u32 id[IAP_PART_ID_SIZE];
+
+ rom_pointer = readl(data->rom + LPC18XX_IAP_TABLE);
+ data->iap.entry = (void *)rom_pointer;
+
+ iap_read_id(data, id);
+ data->part = nxp_lpc_boot_rom_find_part(id, true);
+ if (!data->part) {
+ dev_err(data->dev, "unknown LPC part\n");
+ return -ENODEV;
+ }
+
+ data->partname = data->part->name;
+
+ iap_read_boot_version(data, &data->boot_version);
+
+ iap_read_serial_number(data, ser);
+ add_device_randomness(ser, sizeof(ser));
+ data->soc_dev_attr.soc_id = devm_kasprintf(data->dev, GFP_KERNEL,
+ "%08x%08x%08x%08x", ser[0],
+ ser[1], ser[2], ser[3]);
+
+ return 0;
+}
+
+/*
+ * To determin if IAP is available on a LPC18xx/43xx device the
+ * chip ID in the CREG block must be checked. IAP is only
+ * available on devices with internal Flash memory.
+ *
+ * The part ID can be retrieved using IAP on Flash devices while
+ * Flashless devices has the part ID in OTP. Note that all
+ * LPC18xx/43xx parts have OTP API for writing in boot ROM.
+ */
+static int lpc18xx_boot_rom_setup(struct nxp_rom_api *data)
+{
+ struct regmap *syscon;
+ u32 reg;
+
+ syscon = syscon_regmap_lookup_by_phandle(data->dev->of_node, "syscon");
+ if (IS_ERR(syscon)) {
+ dev_err(data->dev, "unable to get syscon\n");
+ return PTR_ERR(syscon);
+ }
+
+ regmap_read(syscon, LPC18XX_CREG_CHIPID, ®);
+ switch (reg) {
+ case LPC18XX_FLASHLESS_CHIPID0:
+ case LPC18XX_FLASHLESS_CHIPID1:
+ data->partname = "LPC18x0";
+ break;
+
+ case LPC43XX_FLASHLESS_CHIPID0:
+ case LPC43XX_FLASHLESS_CHIPID1:
+ data->partname = "LPC43x0";
+ break;
+
+ case LPC18XX_FLASH_CHIPID0:
+ case LPC18XX_FLASH_CHIPID1:
+ case LPC43XX_FLASH_CHIPID0:
+ case LPC43XX_FLASH_CHIPID1:
+ data->has_iap = true;
+ return 0;
+
+ default:
+ dev_err(data->dev, "unknown chip id\n");
+ return -ENODEV;
+ }
+
+ data->boot_version = readl(data->rom + LPC18XX_ROM_VERSION);
+
+ return 0;
+}
+
+static int nxp_lpc_boot_rom_probe(struct platform_device *pdev)
+{
+ struct nxp_rom_api *data;
+ u8 ver_major, ver_minor;
+ struct resource *res;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->rom = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->rom))
+ return PTR_ERR(data->rom);
+
+ spin_lock_init(&data->lock);
+ data->dev = &pdev->dev;
+
+ ret = lpc18xx_boot_rom_setup(data);
+ if (ret)
+ return ret;
+
+ if (data->has_iap) {
+ ret = nxp_lpc_boot_rom_iap_setup(data);
+ if (ret)
+ return ret;
+ } else {
+ ret = nxp_get_flashless_part_id(data);
+ if (ret)
+ return ret;
+ }
+
+ data->soc_dev_attr.family = "NXP LPC";
+ data->soc_dev_attr.machine = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+ "NXP %s", data->partname);
+
+ ver_major = IAP_BOOT_CODE_VER_MAJOR(data->boot_version);
+ ver_minor = IAP_BOOT_CODE_VER_MINOR(data->boot_version);
+ data->soc_dev_attr.revision = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+ "%u.%u", ver_major,
+ ver_minor);
+
+ dev_info(&pdev->dev, "%s boot code version %s\n",
+ data->soc_dev_attr.machine, data->soc_dev_attr.revision);
+
+ data->soc_dev = soc_device_register(&data->soc_dev_attr);
+ if (IS_ERR(data->soc_dev))
+ return -ENODEV;
+
+ platform_set_drvdata(pdev, data);
+
+ return 0;
+}
+
+static int nxp_lpc_boot_rom_remove(struct platform_device *pdev)
+{
+ struct nxp_rom_api *data = platform_get_drvdata(pdev);
+
+ soc_device_unregister(data->soc_dev);
+
+ return 0;
+}
+
+static const struct of_device_id nxp_lpc_boot_rom_match[] = {
+ {.compatible = "nxp,lpc1850-boot-rom"},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, nxp_lpc_boot_rom_match);
+
+static struct platform_driver nxp_lpc_boot_rom_driver = {
+ .probe = nxp_lpc_boot_rom_probe,
+ .remove = nxp_lpc_boot_rom_remove,
+ .driver = {
+ .name = "nxp-boot-rom",
+ .of_match_table = nxp_lpc_boot_rom_match,
+ },
+};
+module_platform_driver(nxp_lpc_boot_rom_driver);
+
+MODULE_DESCRIPTION("NXP LPC boot ROM firmware driver");
+MODULE_AUTHOR("Joachim Eastwood <manabian@gmail.com>");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] firmware: add driver for lpc18xx boot ROM
From: Joachim Eastwood @ 2016-09-13 19:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds a firmware driver for the boot ROM found on all
NXP LPC18xx/43xx devices. The boot ROM contains serveral APIs that
is used to retrive device specific information and program the
internal Flash and OTP memories.
For now this driver only uses the API in the boot ROM to expose
device information via a 'SoC device'. Support for Flash and OTP
programming will be added later.
Also note that not all APIs are avaliable on all devices. The IAP
API that is used to retrive device information is only avaliable
on devices with Flash. Flashless devices retrive information from
OTP memory. To determin if IAP is avaliable one must check a
specific register in the CREG (syscon) block.
I intend to take this patch set via arm-soc/drivers through my
lpc18xx tree for 4.10.
Joachim Eastwood (3):
firmware: add lpc18xx boot rom driver
firmware: dt: document lpc1850 boot ROM bindings
ARM: dts: lpc18xx: add boot rom node
.../devicetree/bindings/firmware/nxp,boot-rom.txt | 21 ++
arch/arm/boot/dts/lpc18xx.dtsi | 8 +
drivers/firmware/Kconfig | 12 +
drivers/firmware/Makefile | 1 +
drivers/firmware/nxp_lpc_boot_rom.c | 411 +++++++++++++++++++++
5 files changed, 453 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
create mode 100644 drivers/firmware/nxp_lpc_boot_rom.c
--
2.9.3
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Lina Iyer @ 2016-09-13 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87intz665i.fsf@arm.com>
On Tue, Sep 13 2016 at 11:50 -0600, Brendan Jackman wrote:
>
>On Mon, Sep 12 2016 at 18:09, Sudeep Holla wrote:
>> On 12/09/16 17:16, Lina Iyer wrote:
>>> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote:
>>>>
>>>> Hi Lina,
>>>>
>>>> Sorry for the delay here, Sudeep and I were both been on holiday last
>>>> week.
>>>>
>>>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
>>>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
>>>> [...]
>>>>>> This version is *not very descriptive*. Also the discussion we had
>>>>>> on v3
>>>>>> version has not yet concluded IMO. So can I take that we agreed on what
>>>>>> was proposed there or not ?
>>>>>>
>>>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
>>>>> for the new changes in the following patches. Let me know if that makes
>>>>> sense.
>>
>> Please add all possible use-cases in the bindings. Though one can refer
>> the usage examples, it might not cover all usage descriptions. It helps
>> preventing people from defining their own when they don't see examples.
>> Again DT bindings are like specifications, it should be descriptive
>> especially this kind of generic ones.
>>
>>>>
>>>> The not-yet-concluded discussion Sudeep is referring to is at [1].
>>>>
>>>> In that thread we initially proposed the idea of, instead of splitting
>>>> state phandles between cpu-idle-states and domain-idle-states, putting
>>>> CPUs in their own domains and using domain-idle-states for _all_
>>>> phandles, deprecating cpu-idle-states. I've brought this up in other
>>>> threads [2] but discussion keeps petering out, and neither this example
>>>> nor the 8916 dtsi in this patch series reflect the idea.
>>>>
>>> Brendan, while your idea is good and will work for CPUs, I do not expect
>>> other domains and possibly CPU domains on some architectures to follow
>>> this model. There is nothing that prevents you from doing this today,
>
>As I understand it your opposition to this approach is this:
>
>There may be devices/CPUs which have idle states which do not constitute
>"power off". If we put those devices in their own power domain for the
>purpose of putting their (non-power-off) idle state phandles in
>domain-idle-states, we are "lying" because no true power domain exists
>there.
>
>Am I correct that that's your opposition?
>
>If so, it seems we essentially disagree on the definition of a power
>domain, i.e. you define it as a set of devices that are powered on/off
>together while I define it as a set of devices whose power states
>(including idle states, not just on/off) are tied together. I said
>something similar on another thread [1] which died out.
>
>Do you agree that this is basically where we disagree, or am I missing
>something else?
>
>[2] http://www.spinics.net/lists/devicetree/msg141050.html
>
Yes, you are right, I disagree with the definition of a domain around a
device. However, as long as you don't force SoC's to define devices in
the CPU PM domain to have their own virtual domains, I have no problem.
You are welcome to define it the way you want for Juno or any other
platform. I don't want that to be the forced and expected out of all
SoCs. All I am saying here is that the current implementation would
handle your case as well.
Thanks,
Lina
>>> you can specify domains around CPUs in your devicetree and CPU PM will
>>> handle the hierarchy. I don't think its fair to force it on all SoCs
>>> using CPU domains.
>>
>> I disagree. We are defining DT bindings here and it *should* be same for
>> all the SoC unless there is a compelling reason not to. I am fine if
>> those reasons are stated and agreed.
>>
>>> This patchset does not restrict you from organizing
>>> the idle states the way you want it. This revision of the series, clubs
>>> CPU and domain idle states under idle-states umbrella. So part of your
>>> requirement is also satisfied.
>>>
>>
>> I will look at the DTS changes in the series. But we *must* have more
>> description with more examples in the binding document.
>>
>>> You can follow up the series with your new additions, I don't see a
>>> conflict with this change.
>>>
>>
>> If we just need additions, then it should be fine.
^ permalink raw reply
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Ard Biesheuvel @ 2016-09-13 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913173507.GA29678@leverpostej>
On 13 September 2016 at 18:35, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> On Mon, Sep 12, 2016 at 05:15:25PM +0100, Ard Biesheuvel wrote:
>> Move the statically allocated zero page from the .bss section to right
>> before swapper_pg_dir. This allows us to refer to its physical address
>> by simply reading TTBR1_EL1 (which always points to swapper_pg_dir and
>> always has its ASID field cleared), and subtracting PAGE_SIZE.
>
> It might be worth worth mentioning that we want to do this to make
> cpu_set_reserved_ttbr0() as cheap as possible for the TTBR0_SW_PAN
> stuff, as that'll mean we're calling it far more frequently.
>
>> To protect the zero page from inadvertent modification, carve out a
>> segment that covers it as well as idmap_pg_dir[], and mark it read-only
>> in both the primary and the linear mappings of the kernel.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Otherwise, this looks good to me, builds without warnings, and works on
> Juno and Seattle without issue even when I throw the usual set of
> problematic config options at it. Which is to say:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
>
Thanks. But actually, I think it makes sense to make the first
swapper_pg_dir page read-only as well, given that it is only modified
via the fixmap, and we can trivially extend the r/o bss region to end
at 'swapper_pg_dir + PAGE_SIZE'
Thoughts?
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Gregory CLEMENT @ 2016-09-13 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b7d442f9d26249976d7698b6a32db2a3@jamie.lentin.co.uk>
Hi Jamie,
On mar., sept. 13 2016, Jamie Lentin <jm@lentin.co.uk> wrote:
> On 2016-09-13 13:36, Andrew Lunn wrote:
>> On Tue, Sep 13, 2016 at 10:10:41AM +0100, Jamie Lentin wrote:
>>> On 2016-09-12 23:03, Andrew Lunn wrote:
>>> >>Maybe we can instead leave out the PCI support from the new
>>> >>file for now and not delete the legacy board file?
>>>
>>> This seems a reasonable compromise. The PCI card the router comes
>>> with isn't supported by mwl8k mainline anyway (There's STA-only
>>> firmware that can be extracted from a windows driver and PCI IDs
>>> added, but stats reporting uses a different format), so it's not a
>>> huge loss, although many did replace the card with something
>>> Atheros-based.
>>
>> O.K. So dropping the PCI code gets us going forward.
>
> Is an arch/arm/mach-mvebu/orion5x.c also required? Or is continuing to
> use arch/arm/mach-orion5x/board-dt.c until everything has been
> converted the favoured approach?
>
>> Have we missed the merge window?
>
> I got the impression Gregory Clement had merged them? If not a good
> portion of this patchset is uncontroversial generic orion5x stuff,
> it'd be nice to get those in even if none of the router-specific stuff
> doesn't make it.
I applied on mvebu/for-next in order to find any merge conflict. It
seems ok on this side. However, I didn't make the pull request to
arm-soc with these patches so I fear it is too late.
Arnd would you agree to accept a new pull request?
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v10 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
From: Mark Salter @ 2016-09-13 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <706e4bc9-1010-ba2d-55ec-dc6f24611bd3@linaro.org>
On Fri, 2016-09-09 at 17:28 +0800, Hanjun Guo wrote:
> On 2016/9/9 0:34, Mark Salter wrote:
> >
> > On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote:
> > >
> > > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote:
> > > >
> > > >
> > > >
> > > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> > > > >
> > > > >
> > > > > SBBR mentions SPCR as a mandatory ACPI table.??So enable it for ARM64
> > > > >
> > > > > Earlycon should be set up as early as possible.??ACPI boot tables are
> > > > > mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that
> > > > > is called from setup_arch() and that's where we parse SPCR.
> > > > > So it has to be opted-in per-arch.
> > > > >
> > > > > When ACPI_SPCR_TABLE is defined initialization of DT earlycon is
> > > > > deferred until the DT/ACPI decision is done.??Initialize DT earlycon
> > > > > if ACPI is disabled.
> > > > Hi Will, Catalin,
> > > >
> > > > Can you review this patch and consider ACKing it please?
> > > Hanjun, Al, Mark, Graeme -- any comments on this?
> > >
> > > Will
> > I think there is a problem still with systems using 32-bit access to 8250
> > UARTs (i.e. Mustang) but that will need a DBG2 table spec change and
> > followup patch to resolve.
> Hmm, I think you mean we can add patches later with the spec updated,
> and this patch works with SBSA pl011 can go for now?
Yes, I think this series is fine for now.
>
> Thanks
> Hanjun
^ permalink raw reply
* [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE
From: Laura Abbott @ 2016-09-13 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913151325.GF17731@arm.com>
On 09/13/2016 08:14 AM, Will Deacon wrote:
> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote:
>> On 09/13/2016 02:19 AM, Will Deacon wrote:
>>> On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote:
>>>>
>>>> arm64 may need to guarantee the caches are synced. Implement versions of
>>>> the kernel_force_cache API to allow this.
>>>>
>>>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>>>> ---
>>>> v3: Switch to calling cache operations directly instead of relying on
>>>> DMA mapping.
>>>> ---
>>>> arch/arm64/include/asm/cacheflush.h | 8 ++++++++
>>>> arch/arm64/mm/cache.S | 24 ++++++++++++++++++++----
>>>> arch/arm64/mm/flush.c | 11 +++++++++++
>>>> 3 files changed, 39 insertions(+), 4 deletions(-)
>>>
>>> I'm really hesitant to expose these cache routines as an API solely to
>>> support a driver sitting in staging/. I appreciate that there's a chicken
>>> and egg problem here, but we *really* don't want people using these routines
>>> in preference to the DMA API, and I fear that we'll simply grow a bunch
>>> more users of these things if we promote it as an API like you're proposing.
>>>
>>> Can the code not be contained under staging/, as part of ion?
>>>
>>
>> I proposed that in V1 and it was suggested I make it a proper API
>>
>> http://www.mail-archive.com/driverdev-devel at linuxdriverproject.org/msg47654.html
>> http://www.mail-archive.com/driverdev-devel at linuxdriverproject.org/msg47672.html
>
> :/ then I guess we're in disagreement. If ion really needs this stuff
> (which I don't fully grok), perhaps we should be exposing something at
> a higher level from the architecture, so it really can't be used for
> anything other than ion.
I talked/complained about this at a past plumbers. The gist is that Ion
ends up acting as a fake DMA layer for clients. It doesn't match nicely
because clients can allocate both coherent and non-coherent memory.
Trying to use dma_map doesn't work because a) a device for coherency isn't
known at allocation time b) it kills performance. Part of the motivation
for taking this approach is to avoid the need to rework the existing
Android userspace and keep the existing behavior, as terrible as it
is. Having Ion out of staging and not actually usable isn't helpful.
I'll give this all some more thought and hopefully have one or two more
proposals before Connect/Plumbers.
>
> Will
>
Thanks,
Laura
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Martin Blumenstingl @ 2016-09-13 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473780508.10237.22.camel@pengutronix.de>
Hi Philipp,
On Tue, Sep 13, 2016 at 5:28 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Martin,
>
> Am Freitag, den 09.09.2016, 22:36 +0200 schrieb Martin Blumenstingl:
>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> > Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>> >
>> >> On Thu, Sep 8, 2016 at 10:53 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> >>> On 08/09/16 21:42, Kevin Hilman wrote:
>> >>>>
>> >>>> Ben Dooks <ben.dooks@codethink.co.uk> writes:
>> >>>>
>> >>>>> On 08/09/16 20:52, Martin Blumenstingl wrote:
>> >>>>>>
>> >>>>>> On Thu, Sep 8, 2016 at 9:35 PM, Kevin Hilman <khilman@baylibre.com>
>> >>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
>> >>>>>>>> + if (IS_ERR(phy)) {
>> >>>>>>>> + dev_err(&pdev->dev, "failed to create PHY\n");
>> >>>>>>>> + return PTR_ERR(phy);
>> >>>>>>>> + }
>> >>>>>>>> +
>> >>>>>>>> + if (usb_reset_refcnt++ == 0) {
>> >>>>>>>> + ret = device_reset(&pdev->dev);
>> >>>>>>>> + if (ret) {
>> >>>>>>>> + dev_err(&phy->dev, "Failed to reset USB PHY\n");
>> >>>>>>>> + return ret;
>> >>>>>>>> + }
>> >>>>>>>> + }
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> The ref count + reset here looks like something that could/should be
>> >>>>>>> handled in a runtime PM callback.
>> >>>>>>
>> >>>>>> Unfortunately that doesn't work (as Jerome found out) because both
>> >>>>>> PHYs are sharing the same reset line.
>> >>>>>> So if the second PHY would call device_reset then it would also reset
>> >>>>>> the first PHY!
>> >>>>>>
>> >>>>>> There's a comment above the declaration of usb_reset_refcnt which
>> >>>>>> tries to explain this:
>> >>>>>> "The PHYs are sharing a common reset line -> we are only allowed to
>> >>>>>> reset once for all PHYs."
>> >>>>>> Maybe I should move this comment to the "if (usb_reset_refcnt++ == 0)
>> >>>>>> {" line to make it easier to see?
>> >>>>>>
>> >>>>>
>> >>>>> pm-runtime has refcounting in it. When one of the nodes turns on,
>> >>>>> the pm-runtime will call your driver to say there is a user when
>> >>>>> this first use turns up.
>> >>>>>
>> >>>>> If all the sub-phys turn off and drop their refcount then the driver
>> >>>>> is called to say there are no more users and you can go to sleep.
>> >>>>
>> >>>>
>> >>>> After a chat w/Martin on IRC, It turns out runtime PM wont help here.
>> >>>>
>> >>>> The reason is because there are physically two PHY devices[1]. Those 2
>> >>>> devices will be treated independely by runtime PM, and have separate
>> >>>> use-counting, which means doing what I proposed would cause a reset to
>> >>>> happen when either device was probed.
>> >>>>
>> >>>> So, I think it's OK as it is.
>> >>>
>> >>>
>> >>> Surely you can do pm_runtime_get/put on the phy's parent platform
>> >>> device and do it that way?
>> >> could you please be more specific with that (do you mean pdev->dev.parent)?
>> >> so we would use pm_runtime_{get_sync,put} with the parent, while we
>> >> would still define the runtime_resume in our driver.
>> >
>> > You'd also need to do get/put on the children, but yes, that's what Ben
>> > is suggesting.
>> >
>> > However, the problem with all of the solutions proposed (runtime PM ones
>> > included) is that we're forcing a board-specific design issue (2 devices
>> > sharing a reset line) into a driver that should not have any
>> > board-specific assumptions in it.
>> >
>> > For example, if this driver is used on another platform where different
>> > PHYs have different reset lines, then one of them (the unlucky one who
>> > is not probed first) will never get reset. So any form of per-device
>> > ref-counting is not a portable solution.
>> indeed, so in simple words we would need something like
>> reset_control_do_once(rstc, RESET/ASSERT/DEASSERT) which would
>> remember internally if any action has already been executed: if not it
>> does a _reset, _assert or _deassert and otherwise it does nothing.
>>
>> > I'm not sure yet how the reset framework is supposed to handle shared
>> > reset lines, but that needs some investigation. I quick glance and it
>> > seems that reset controllers can have shared lines, so that should be
>> > investigated.
>> I added Philipp and Hans to this thread - maybe they can comment on this.
>> To sum it up, our problem is:
>> - there are two separate USB PHYs on Meson GXBB
>> - both are sharing the same reset line (provided by the reset-meson driver)
>> - during initialization of the PHYs we must only call
>> reset_control_reset(rstc) once (if we do it for the first *and* second
>> PHY then the first PHY gets confused once the second PHY uses the
>> reset because the first PHY's state is reset as well)
>
> If you have an initially asserted reset line and you can enable the
> first module by deasserting the reset via reset_control_deassert (and
> reset_control_assert to signal when the module may be disabled again
> after use), shared resets are for you.
>
> If you need a reset pulse or have no direct control over the reset line,
> (device_reset), the reset framework currently has no solution for this.
> The ugly thing about reset_control_once would be that it can't re-reset
> modules when unloading and reloading driver modules.
The corresponding reset driver in question is reset-meson, which only
implements reset (assert/deassert are not implemented). However, I
don't know if this is due to hardware design.
I think the hardware implements the latter, but maybe Neil can give
more information here (I currently don't have access to my board so I
cannot test how the hardware actually behaves).
> A real solution for shared reset lines with reset pulses would have to
> be some kind of reset request framework where if one module requests a
> reset, the other module sharing the reset could be notified, and then
> either veto the reset or, if possible, cease operations, store its
> state, and prepare to be reset, too, and afterwards restore state. I'd
> prefer not to think about this too much unless absolutely necessary.
I'm not sure if this would work in our case: one PHY instance would
have to know if the other has already triggered the reset or not.
Regards,
Martin
^ permalink raw reply
* [arm:sa1100 80/81] arch/arm/mach-pxa/mainstone.c:560: undefined reference to `gpio_reg_init'
From: kbuild test robot @ 2016-09-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git sa1100
head: 36b075e9681a293ef57aaa107ab394bc879a0807
commit: 4c76c25bd4f755e2302807f99b75ff9954c036d1 [80/81] ARM: pxa/mainstone: convert PCMCIA to use MAX1600 driver and gpiod APIs
config: arm-mainstone_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4c76c25bd4f755e2302807f99b75ff9954c036d1
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/mach-pxa/built-in.o: In function `mainstone_init':
>> arch/arm/mach-pxa/mainstone.c:560: undefined reference to `gpio_reg_init'
arch/arm/mach-pxa/mainstone.c:563: undefined reference to `gpio_reg_init'
vim +560 arch/arm/mach-pxa/mainstone.c
554 {
555 int SW7 = 0; /* FIXME: get from SCR (Mst doc section 3.2.1.1) */
556
557 pxa2xx_mfp_config(ARRAY_AND_SIZE(mainstone_pin_config));
558
559 /* Register board control register(s) as GPIOs */
> 560 gpio_reg_init(NULL, (void __iomem *)&MST_PCMCIA0, -1, 11,
561 "mst-pcmcia0", MST_PCMCIA_INPUTS, 0, NULL,
562 NULL, mst_pcmcia0_irqs);
563 gpio_reg_init(NULL, (void __iomem *)&MST_PCMCIA1, -1, 11,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 12287 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160914/c8dff7fd/attachment.obj>
^ permalink raw reply
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Bjorn Andersson @ 2016-09-13 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913093107.GA10953@griffinp-ThinkPad-X1-Carbon-2nd>
On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> Hi Vinod & Bjorn,
>
> [..]
>
> On Mon, 05 Sep 2016, Peter Griffin wrote:
>
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> > a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> >
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> > was found during testing now that the platform boots without clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading was attempted.
> >
> > regards,
> >
> > Peter.
> >
> > Changes since v8:
> > - Add MODULE_ALIAS (Vinod)
> > - devm_kzalloc to devm_kcalloc (Vinod)
> > - quisce tasklet initialised by vchan_init() (Vinod)
> > - Don't make SLIM rproc user selectable (Bjorn)
> > - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> > - Various code style nits / commit message change (Lee)
> > - Separate patch for '\n' kconfig removal (Vinod)
>
> I hate to send a ping,
Sorry about that.
> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
>
I think the remoteproc part looks good.
Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.
I do however think that the dts patches should go through arm-soc.
Regards,
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