* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Ard Biesheuvel @ 2016-11-10 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109224955.GO14322@bhelgaas-glaptop.roam.corp.google.com>
On 10 November 2016 at 06:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
>> Hi Bjorn,
>>
>> On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
>> >> Hi Bjorn,
>> >>
>> [...]
>> >>
>> >> We're working to add the PNP0C02 resource to future firmware, but it's
>> >> not in the current firmware. Are dmesg and /proc/iomem from the
>> >> current firmware interesting or should we wait for the update to file?
>> >
>> > Note that the ECAM space is not the only thing that should be
>> > described via these PNP0C02 devices. *All* non-enumerable resources
>> > should be described by the _CRS method of some ACPI device. Here's a
>> > sample from my laptop:
>> >
>> > PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
>> > system 00:01: [io 0x1800-0x189f] could not be reserved
>> > system 00:01: [io 0x0800-0x087f] has been reserved
>> > system 00:01: [io 0x0880-0x08ff] has been reserved
>> > system 00:01: [io 0x0900-0x097f] has been reserved
>> > system 00:01: [io 0x0980-0x09ff] has been reserved
>> > system 00:01: [io 0x0a00-0x0a7f] has been reserved
>> > system 00:01: [io 0x0a80-0x0aff] has been reserved
>> > system 00:01: [io 0x0b00-0x0b7f] has been reserved
>> > system 00:01: [io 0x0b80-0x0bff] has been reserved
>> > system 00:01: [io 0x15e0-0x15ef] has been reserved
>> > system 00:01: [io 0x1600-0x167f] has been reserved
>> > system 00:01: [io 0x1640-0x165f] has been reserved
>> > system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
>> > system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
>> > system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
>> > system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
>> > system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
>> > system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
>> > system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
>> > system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
>> > system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
>> >
>> > Do you have firmware in the field that may not get updated? If so,
>> > I'd like to see the whole solution for that firmware, including the
>> > MCFG quirk (which tells the PCI core where the ECAM region is) and
>> > whatever PNP0C02 quirk you figure out to actually reserve the region.
>> >
>> > I proposed a PNP0C02 quirk to Duc along these lines of the below. I
>> > don't actually know if it's feasible, but it didn't look as bad as I
>> > expected, so I'd kind of like somebody to try it out. I think you
>> > would have to call this via a DMI hook (do you have DMI on arm64?),
>> > maybe from pnp_init() or similar.
>>
>> We do have SMBIOS/DMI on arm64, but we have been successful so far not
>> to rely on it for quirks, and we'd very much like to keep it that way.
>>
>> Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
>> there is a better way to wire up the reservation code to the
>> information exposed by ACPI?
>
> I'm open to other ways, feel free to propose one :)
>
> If you do a quirk, you need some way to identify the machine/firmware
> combination, because you don't want to apply the quirk on every
> machine. You're trying to work around a firmware issue, so you
> probably want something tied to the firmware version. On x86, that's
> typically done with DMI.
>
I think I misunderstood the purpose of the example: that should only
be necessary if the _CRS methods are missing from the firmware, right?
If we update the firmware to cover all non-enumerable resources by
such a method, we shouldn't need any such quirks at all IIUC
^ permalink raw reply
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3693445.TSdZGaiT9S@wuerfel>
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wpgbekwg.fsf@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 10:36:47 +0100, Gregory CLEMENT wrote:
> >> - bootrom {
> >> + bootrom at 0 {
> >> compatible = "marvell,bootrom";
> >> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
> >
> > I am still not sure whether this "0" unit address is correct compared
> > to the reg property being passed.
>
> I chose to use the adress register inside the window memory.
Which I think is bogus, as my example below highlighted.
> > A good example of why I'm worried is the sa-sram case:
> >
> > + crypto_sram0: sa-sram0 at 0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> >
> > + crypto_sram1: sa-sram1 at 0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> >
> > The node names should be just "sram" without a number. Indeed for UARTs
> > for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
> > uart1 at ABC. But then, if you do that, with your scheme, you end up with
> > both nodes named sa-sram at 0.
> >
> > Which clearly shows that the way you set this unit-address is not
> > correct: those two devices are mapped at completely different
> > locations, but you end up with an identical unit address.
> >
> > I have no idea what is the rule for setting the unit address in this
> > case, but I'm pretty sure the rule you've chosen is not good.
>
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
>
> crypto_sram0: sa-sram at 09_09_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
>
> crypto_sram1: sa-sram at 09_05_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.
I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.
Rob, Mark?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+aJhH11ty3xWQ5-CLCrPA5xH-dr_nVb8JCKZEvgJcm6Ha3xaA@mail.gmail.com>
On 10 November 2016 at 19:33, Nathan Rossi <nathan@nathanrossi.com> wrote:
> On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
>> + Nathan
>>
>> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>>
>>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>>> the first 512k). In older kernels, this was masked by the
>>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>>> address and not a size anyway.
>>>
>>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>>> kernel")
>>>
>>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
>
> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>
> For reference this causes problems with DEBUG_RODATA (which changed to
Sorry typo -> s/causes/caused/, as in "... this [incorrect reserving
of the lower 512K] caused ...".
Regards,
Nathan
> default yes for CPU_V7 in v4.6) due to padding memory between
> .head.text and .text, allowing memory below 0x80000 to be available
> for allocation as non-reserved memory.
>
> Regards,
> Nathan
>
>>> ---
>>> Found when migrating from 4.1 to 4.6.
>>>
>>> arch/arm/mach-zynq/common.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>>> index 6cefdb8..75885bc 100644
>>> --- a/arch/arm/mach-zynq/common.c
>>> +++ b/arch/arm/mach-zynq/common.c
>>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>>> static void __init zynq_memory_init(void)
>>> {
>>> if (!__pa(PAGE_OFFSET))
>>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>>> }
>>>
>>> static struct platform_device zynq_cpuidle_device = {
>>> --
>>> 2.9.3
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
>> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
>> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110092221.0219490b@free-electrons.com>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
>
>> - bootrom {
>> + bootrom at 0 {
>> compatible = "marvell,bootrom";
>> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
>
> I am still not sure whether this "0" unit address is correct compared
> to the reg property being passed.
I chose to use the adress register inside the window memory.
>
> A good example of why I'm worried is the sa-sram case:
>
> + crypto_sram0: sa-sram0 at 0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
> + crypto_sram1: sa-sram1 at 0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>
> The node names should be just "sram" without a number. Indeed for UARTs
> for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
> uart1 at ABC. But then, if you do that, with your scheme, you end up with
> both nodes named sa-sram at 0.
>
> Which clearly shows that the way you set this unit-address is not
> correct: those two devices are mapped at completely different
> locations, but you end up with an identical unit address.
>
> I have no idea what is the rule for setting the unit address in this
> case, but I'm pretty sure the rule you've chosen is not good.
I don't know if there is an existing rules for this case. But I see your
concern. What I propose then is to expose the memory windows ID by
adding the target and the attributes like this:
crypto_sram0: sa-sram at 09_09_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
crypto_sram1: sa-sram at 09_05_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+8kBYQwcUUcL1Z71Geij4EU3pjcv29=r8ndqSLW8iZDw@mail.gmail.com>
On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
> + Nathan
>
> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>
>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>> the first 512k). In older kernels, this was masked by the
>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>> address and not a size anyway.
>>
>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>> kernel")
>>
>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Tested-by: Nathan Rossi <nathan@nathanrossi.com>
For reference this causes problems with DEBUG_RODATA (which changed to
default yes for CPU_V7 in v4.6) due to padding memory between
.head.text and .text, allowing memory below 0x80000 to be available
for allocation as non-reserved memory.
Regards,
Nathan
>> ---
>> Found when migrating from 4.1 to 4.6.
>>
>> arch/arm/mach-zynq/common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>> index 6cefdb8..75885bc 100644
>> --- a/arch/arm/mach-zynq/common.c
>> +++ b/arch/arm/mach-zynq/common.c
>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>> static void __init zynq_memory_init(void)
>> {
>> if (!__pa(PAGE_OFFSET))
>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>> }
>>
>> static struct platform_device zynq_cpuidle_device = {
>> --
>> 2.9.3
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Geert Uytterhoeven @ 2016-11-10 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrcAN_pqgtGaUanfB2zh97zGcL23m5VDtJ3g==NJeRrfA@mail.gmail.com>
Hi Ulf,
On Wed, Nov 9, 2016 at 7:27 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
>> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
>> eSDHC controller. To match the SoC version and revision, 15 previous version
>> patchsets had tried many methods but all of them were rejected by reviewers.
>> Such as
>> - dts compatible method
>> - syscon method
>> - ifdef PPC method
>> - GUTS driver getting SVR method
>> Anrd suggested a soc_device_match method in v10, and this is the only available
>> method left now. This v11 patchset introduces the soc_device_match interface in
>> soc driver.
>>
>> The first four patches of Yangbo are to add the GUTS driver. This is used to
>> register a soc device which contain soc version and revision information.
>> The other three patches introduce the soc_device_match method in soc driver
>> and apply it on esdhc driver to fix this bug.
>>
>> ---
>> Changes for v15:
>> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
>> since the work had been done by below patch on ShawnGuo's linux tree.
>> 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
>> and DCFG'
>> - Fixed error code issue in guts driver
>> Changes for v16:
>> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
>> - Added a bug-fix patch from Geert
>> ---
>>
>> Arnd Bergmann (1):
>> base: soc: introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (1):
>> base: soc: Check for NULL SoC device attributes
> Thanks, applied on my mmc tree for next!
Oops, the above two commits (plus two more enhancements) are also a dependency
for Samsung and Renesas. Hence the plan was to use an immutable branch for
that...
Ulf, would it still be possible to replace these two commits in mmc/next:
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of the immutable branch I've just created?
Cfr, the other thread "[PATCH v2 0/7] soc: renesas: Identify SoC and register
with the SoC bus".
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6723536.97ljqcB8tS@wuerfel>
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Heiko Stübner @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9eeb3d84-f850-4b76-ce6a-67cc92d6de3b@rock-chips.com>
Am Donnerstag, 10. November 2016, 10:54:49 schrieb wlf:
> Hi Doug,
>
> ? 2016?11?10? 04:54, Doug Anderson ??:
> > Hi,
> >
> > On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> wrote:
> >> We found that the system crashed due to 480MHz output clock of
> >> USB2 PHY was unstable after clock had been enabled by gpu module.
> >>
> >> Theoretically, 1 millisecond is a critical value for 480MHz
> >> output clock stable time, so we try to change the delay time
> >> to 1.2 millisecond to avoid this issue.
> >>
> >> Signed-off-by: William Wu <wulf@rock-chips.com>
> >> ---
> >>
> >> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
> >> b/drivers/phy/phy-rockchip-inno-usb2.c index ecfd7d1..8f2d2b6 100644
> >> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> >> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> >> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct
> >> clk_hw *hw)>>
> >> return ret;
> >>
> >> /* waitting for the clk become stable */
> >>
> >> - mdelay(1);
> >> + udelay(1200);
> >
> > Several people who have seen this patch have expressed concern that a
> > 1.2 ms delay is pretty long for something that's supposed to be
> > "atomic" like a clk_enable(). Consider that someone might call
> > clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
> > latency is not so great.
> >
> > It seems like this clock should be moved to be enabled in "prepare"
> > and the "enable" should be a no-op. This is a functionality change,
> > but I don't think there are any real users for this clock at the
> > moment so it should be fine.
> >
> > (of course, the 1 ms latency that existed before this patch was still
> > pretty bad, but ...)
>
> Thanks a lot for your suggestion.
> I agree with you. clk_enable() will call spin_lock_irqsave() to disable
> interrupt, and we add
> more than 1ms in clk_enable may cause big latency.
>
> And according to clk_prepare() description:
> In a simple case, clk_prepare can be used instead of clk_enable to
> ungate a clk if the
> operation may sleep. One example is a clk which is accessed over I2c.
>
> So maybe we can remove the clock to clk_prepare.
>
> Hi Heiko, Frank,
> What do you think of it?
moving to clk_prepare sounds sensible. That way you can switch from delay to
sleep functions as well.
Heiko
^ permalink raw reply
* [PATCH] regulator: gpio: properly check return value of of_get_named_gpio
From: Jisheng Zhang @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
The function of_get_named_gpio() could return -ENOENT, -EPROBE_DEFER
-EINVAL and so on. Currently, for the optional property "enable-gpio",
we only check -EPROBE_DEFER, this is not enough since there may be
misconfigured "enable-gpio" in the DTB, of_get_named_gpio() will return
-EINVAL in this case, we should return immediately here. And for the
optional property "gpios", we didn't check the return value, the driver
will continue to the point where gpio_request_array() is called, it
doesn't make sense to continue if we got -EPROBE_DEFER or -EINVAL here.
This patch tries to address these two issues by properly checking the
return value of of_get_named_gpio.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/regulator/gpio-regulator.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
index 83e89e5..0fce06a 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -162,8 +162,8 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
- if (config->enable_gpio == -EPROBE_DEFER)
- return ERR_PTR(-EPROBE_DEFER);
+ if (config->enable_gpio < 0 && config->enable_gpio != -ENOENT)
+ return ERR_PTR(config->enable_gpio);
/* Fetch GPIOs. - optional property*/
ret = of_gpio_count(np);
@@ -190,8 +190,11 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
for (i = 0; i < config->nr_gpios; i++) {
gpio = of_get_named_gpio(np, "gpios", i);
- if (gpio < 0)
+ if (gpio < 0) {
+ if (gpio != -ENOENT)
+ return ERR_PTR(gpio);
break;
+ }
config->gpios[i].gpio = gpio;
if (proplen > 0) {
of_property_read_u32_index(np, "gpios-states",
--
2.10.2
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-10 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5824165A.4040303@hisilicon.com>
On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> On 2016/11/10 5:34, Arnd Bergmann wrote:
> > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> >>>> + /*
> >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
> >>> indirectIO.
> >>>> + * It will separate indirectIO range from pci host bridge to
> >>>> + * avoid the possible PIO conflict.
> >>>> + * Set the indirectIO range directly here.
> >>>> + */
> >>>> + lpcdev->io_ops.start = 0;
> >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> >>>> + lpcdev->io_ops.devpara = lpcdev;
> >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
> >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
> >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> >>>
> >>> I have to look at patch 2 in more detail again, after missing a few
> >>> review
> >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> >>> range here, and would hope that we can just go through the same
> >>> assignment of logical port ranges that we have for PCI buses,
> >>> decoupling
> >>> the bus addresses from the linux-internal ones.
> >>
> >> The point here is that we want to avoid any conflict/overlap between
> >> the LPC I/O space and the PCI I/O space. With the assignment above
> >> we make sure that LPC never interfere with PCI I/O space.
> >
> > But we already abstract the PCI I/O space using dynamic registration.
> > There is no need to hardcode the logical address for ISA, though
> > I think we can hardcode the bus address to start at zero here.
>
> Do you means that we can pick up the maximal I/O address from all children's
> device resources??
The driver should not look at the resources of its children, just
register a range of addresses dynamically, as I suggested in an
earlier review.
Your current version has
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr, value, sizeof(type)); \
Instead, just subtract the start of the range from the logical
port number to transform it back into a bus-local port number:
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr - arm64_extio_ops->start, value, sizeof(type)); \
We know that the ISA/LPC bus can only have up to 65536 ports,
so you can register all of those, or possibly limit it further to
1024 or 4096 ports, whichever matches the bus implementation.
Arnd
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Marc Zyngier @ 2016-11-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478721480-24852-1-git-send-email-wei@redhat.com>
Hi Wei,
On 09/11/16 19:57, Wei Huang wrote:
> This patch moves ARMv8-related perf event definitions from perf_event.c
> to asm/perf_event.h; so KVM code can use them directly. This also help
> remove a duplicated definition of SW_INCR in perf_event.h.
>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
> 2 files changed, 160 insertions(+), 162 deletions(-)
>
> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> index 2065f46..6c7b18b 100644
> --- a/arch/arm64/include/asm/perf_event.h
> +++ b/arch/arm64/include/asm/perf_event.h
> @@ -46,7 +46,166 @@
> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>
> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
> +/*
> + * ARMv8 PMUv3 Performance Events handling code.
> + * Common event types.
> + */
> +
> +/* Required events. */
> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
In my initial review, I asked for the "required" events to be moved to a
shared location. What's the rational for moving absolutely everything?
KVM only needs to know about ARMV8_PMUV3_PERFCTR_SW_INCR and
ARMV8_PMUV3_PERFCTR_CPU_CYCLES, so I thought that moving the above six
events (and maybe the following two) would be enough.
Also, you've now broken the build by dropping
ARMV8_PMU_EVTYPE_EVENT_SW_INCR without amending it use in the KVM PMU
code (see the kbuild report).
> +
> +/* At least one of the following is required. */
> +#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> +#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> +
> +/* Common architectural events. */
> +#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> +#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> +#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> +#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> +#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> +#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> +#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> +#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> +#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> +#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> +#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> +#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> +
> +/* Common microarchitectural events. */
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> +#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> +#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> +#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> +#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> +#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> +#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> +
> +/* ARMv8 recommended implementation defined event types */
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> +
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> +
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> +
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> +
> +#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> +#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> +#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> +#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> +#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> +#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> +#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> +#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> +#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> +#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> +#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> +#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> +#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> +#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> +#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> +
> +#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> +#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> +#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> +#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> +#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> +#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> +#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> +#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> +
> +/* ARMv8 Cortex-A53 specific event types. */
> +#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> +
> +/* ARMv8 Cavium ThunderX specific event types. */
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
>
> /*
> * Event filters for PMUv3
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index a9310a6..108ba40 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -29,167 +29,6 @@
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
>
> -/*
> - * ARMv8 PMUv3 Performance Events handling code.
> - * Common event types.
> - */
> -
> -/* Required events. */
> -#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> -#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> -#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
> -
> -/* At least one of the following is required. */
> -#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> -#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> -
> -/* Common architectural events. */
> -#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> -#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> -#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> -#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> -#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> -#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> -#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> -#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> -#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> -#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> -#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> -#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> -
> -/* Common microarchitectural events. */
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> -#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> -#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> -#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> -#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> -#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> -#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> -
> -/* ARMv8 recommended implementation defined event types */
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> -
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> -
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> -
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> -
> -#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> -#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> -#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> -#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> -#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> -#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> -#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> -#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> -#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> -#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> -#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> -#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> -#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> -#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> -#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> -
> -#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> -#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> -#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> -#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> -#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> -#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> -#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> -#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> -
> -/* ARMv8 Cortex-A53 specific event types. */
> -#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> -
> -/* ARMv8 Cavium ThunderX specific event types. */
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
> -
> /* PMUv3 HW events mapping. */
>
> /*
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] STi DT update for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this second round of STi dts update for v4.10 :
The following changes since commit 97a0b97f9e8197429eee5f87ce14373f73dbd9d3:
ARM: dts: stih410-clocks: Add PROC_STFE as a critical clock (2016-10-20 16:20:26 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-4.10-round2
for you to fetch changes up to 64783ea7de0bff3de77cfdff1ed76428c288faac:
ARM: dts: STiHxxx-b2120: change sound card name (2016-11-10 09:52:49 +0100)
----------------------------------------------------------------
STi dts update:
Change sound card name for B2120
Enable sound card for B2260
Remove stih415-clks.h
Identify critical clocks for STiH407
Fix typo in stih407-pinctrl.dtsi
----------------------------------------------------------------
Arnaud Pouliquen (2):
ARM: dts: STiH410-B2260: enable sound card
ARM: dts: STiHxxx-b2120: change sound card name
Geert Uytterhoeven (1):
ARM: dts: STiH407: DT fix s/interrupts-names/interrupt-names/
Patrice Chotard (1):
ARM: dts: remove stih415-clks.h
Peter Griffin (1):
ARM: dts: stih407-clocks: Identify critical clocks
arch/arm/boot/dts/stih407-clock.dtsi | 10 ++++++++++
arch/arm/boot/dts/stih407-pinctrl.dtsi | 2 +-
arch/arm/boot/dts/stih410-b2260.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +-
include/dt-bindings/clock/stih415-clks.h | 16 ----------------
5 files changed, 34 insertions(+), 18 deletions(-)
delete mode 100644 include/dt-bindings/clock/stih415-clks.h
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider the second round of multi_v7_defconfig updates for v4.10 :
The following changes since commit 620c52f4db4d47e1f33c64e641392fe575d5397f:
ARM: multi_v7_defconfig: Remove stih41x phy Kconfig symbol. (2016-10-20 17:05:08 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git sti-defconfig-for-4.10-round2
for you to fetch changes up to 57dae748959d0abae2b382ccee68621a82f827c8:
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
----------------------------------------------------------------
Remove STiH415/416 specific IPs
As STiH415/416 have been removed from kernel, remove IPs only
found on these socs, remove ST_THERMAL_SYSCFG.
----------------------------------------------------------------
Patrice Chotard (1):
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28234714-3994-6747-9cf8-1ff0b3257f7a@gmail.com>
Hi,
On 09-11-16 21:45, Jacek Anaszewski wrote:
> Hi Tony,
>
> On 11/09/2016 08:23 PM, Tony Lindgren wrote:
>> Hi,
>>
>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>
>> On my omap dm3730 based test system, idle power consumption is over 70
>> times higher now with this patch! It goes from about 6mW for the core
>> system to over 440mW during idle meaning there's some busy timer now
>> active.
>>
>> Reverting this patch fixes the issue. Any ideas?
>
> Thanks for the report. This is probably caused by sysfs_notify_dirent().
> I'm afraid that we can't keep this feature in the current shape.
> Hans, I'm dropping the patch. We probably will have to delegate this
> call to a workqueue task. Think about use cases when the LED is blinked
> with high frequency e.g. from ledtrig-disk.c.
sysfs_notify_dirent() already uses a workqueue, here is the actual
implementation of it (from fs/kernfs/file.c) :
void kernfs_notify(struct kernfs_node *kn)
{
static DECLARE_WORK(kernfs_notify_work, kernfs_notify_workfn);
unsigned long flags;
if (WARN_ON(kernfs_type(kn) != KERNFS_FILE))
return;
spin_lock_irqsave(&kernfs_notify_lock, flags);
if (!kn->attr.notify_next) {
kernfs_get(kn);
kn->attr.notify_next = kernfs_notify_list;
kernfs_notify_list = kn;
schedule_work(&kernfs_notify_work);
}
spin_unlock_irqrestore(&kernfs_notify_lock, flags);
}
So using a workqueue is not going to help. Note that I already
feared this, which is why my initial implementation only called
sysfs_notify_dirent() for user initiated changes and not for
triggers / blinking.
I think we may need to reconsider what getting the brightness
sysfs atrribute actually returns. Currently when a LED is
blinking it will return 0 resp. the actual brightness depending
on when in the blink cycle the user reads the brightness
sysfs atrribute.
So a user can do "echo 128 > brightness && cat brightness" and
get out 0, or 128, depending purely on timing.
This seems to contradict what Documentation/ABI/testing/sysfs-class-led
has to say:
What: /sys/class/leds/<led>/brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Set the brightness of the LED. Most LEDs don't
have hardware brightness support, so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds/<led>/max_brightness.
Writing 0 to this file clears active trigger.
Writing non-zero to this file while trigger is active changes the
top brightness trigger is going to use.
Even though it only talks about writing, the logical thing would be for
reading to be the exact opposite of writing, so we would get:
Reading from this file while a trigger is active returns the
top brightness trigger is going to use.
The current docs say not about (sw) blinking, but that should be treated just
like a trigger IMHO.
If we can get consensus on what the read behavior for the brightness attribute
should be, then I think that a better poll() behavior will automatically follow
from that.
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: add nand controller nodes
From: Steffen Trumtrar @ 2016-11-10 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7127bcd-ec0e-cb47-592d-06f404857d50@kernel.org>
On Wed, Nov 09, 2016 at 12:48:21PM -0600, Dinh Nguyen wrote:
>
>
> On 11/09/2016 01:35 AM, Steffen Trumtrar wrote:
> > Add the denali nand controller to the socfpga dtsi.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/boot/dts/socfpga.dtsi | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index 9f48141270b8..6b0c23ca5e88 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -700,6 +700,19 @@
> > status = "disabled";
> > };
> >
> > + nand0: nand at ff900000 {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + compatible = "denali,denali-nand-dt";
> > + reg = <0xff900000 0x100000>,
> > + <0xffb80000 0x10000>;
> > + reg-names = "nand_data", "denali_reg";
> > + interrupts = <0x0 0x90 0x4>;
> > + dma-mask = <0xffffffff>;
> > + clocks = <&nand_clk>;
> > + status = "disabled";
> > + };
> > +
> > ocram: sram at ffff0000 {
> > compatible = "mmio-sram";
> > reg = <0xffff0000 0x10000>;
> >
>
> Since there's only 1 NAND node, do we need to call the node "nand0"? No
> need to resend a patch, I can change it locally if we agree that the
> node should be just:
>
> nand: nand at ff900000
>
Okay with me. Go ahead.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109192301.GS26979@atomide.com>
Hi,
On 09-11-16 20:23, Tony Lindgren wrote:
> Hi,
>
> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> the sysfs brightness attr for changes.") breaks runtime PM for me.
>
> On my omap dm3730 based test system, idle power consumption is over 70
> times higher now with this patch! It goes from about 6mW for the core
> system to over 440mW during idle meaning there's some busy timer now
> active.
Do you have any blinking LEDs or LED triggers defined on the system ?
> Reverting this patch fixes the issue. Any ideas?
All I can think of is something calling led_set_brightness quite often,
the patch in question makes led_set_brightness somewhat more expensive,
but it should not cause such a big difference unless something is
really calling led_set_brightness quite often maybe something is calling
it with the same value all the time ?
Regards,
Hans
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-11-10 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
Hi, Ben,
On 2016/11/9 7:16, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>>>
>>> For arm64, there is no I/O space as other architectural platforms, such as
>>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>>> known port addresses are used to control the corresponding target devices, for
>>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>>> normal MMIO mode in using.
>>
>> This has nothing to do with arm64. Hardware with this kind of indirect
>> bus access could be integrated with a variety of CPU architectures. It
>> simply hasn't been, yet.
>
> On some ppc's we also use similar indirect access methods for IOs. We
> have a generic infrastructure for re-routing some memory or IO regions
> to hooks.
>
I am interested on the generic infrastructure on PPC.
Could you point out where those drivers are?
want to take a look..
Thanks,
Zhichang
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
>>> To drive these devices, this patch introduces a method named indirect-IO.
>>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>>> redefined. When upper layer drivers call in/out with those known legacy port
>>> addresses to access the peripherals, the hooking functions corrresponding to
>>> those target peripherals will be called. Through this way, those upper layer
>>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> As above, this has nothing to do with arm64, and as such, should live in
>> generic code, exactly as we would do if we had higher-level ISA
>> accessor ops.
>>
>> Regardless, given the multi-instance case, I don't think this is
>> sufficient in general (and I think we need higher-level ISA accessors
>> to handle the indirection).
>
> Multi-instance with IO is tricky to do generically because archs already
> have all sort of hacks to deal with the fact that inb/outb don't require
> an explicit ioremap, so an IO resource can take all sort of shape depending
> on the arch.
>
> Overall it boils down to applying some kind of per-instance "offset" to
> the IO port number though.
>
^ permalink raw reply
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Thomas Petazzoni @ 2016-11-10 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174440.GA24717@obsidianresearch.com>
Hello,
On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote:
> The firmware may setup the mbus to access PCI-E and indicate this
> has happened with a ranges mapping for the PCI-E ID. If this happens
> then the mbus setup and the pci dynamic setup conflict, creating
> problems.
>
> Have PCI-E assume control of the firmware specified default mapping by
> setting the value of the bridge window to match the firmware mapping.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Sorry for the late feedback. I am not sure to fully understand what you
are trying to do here.
However, one thing that confuses me specifically is how can the kernel
get any MBus mapping set up by the firmware? Indeed, when the
mvebu-mbus driver initializes, it destroys all existing MBus windows
that might have been left by the firmware/bootloader:
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
size_t sdramwins_size,
phys_addr_t mbusbridge_phys_base,
size_t mbusbridge_size,
bool is_coherent)
[...]
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
Why does Linux needs to rely on what the firmware has setup in terms of
MBus windows? Why can't Linux just find out the right BAR base/size
like it is doing for all other devices?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-5-gregory.clement@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
> - bootrom {
> + bootrom at 0 {
> compatible = "marvell,bootrom";
> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
I am still not sure whether this "0" unit address is correct compared
to the reg property being passed.
A good example of why I'm worried is the sa-sram case:
+ crypto_sram0: sa-sram0 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
+ crypto_sram1: sa-sram1 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
The node names should be just "sram" without a number. Indeed for UARTs
for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
uart1 at ABC. But then, if you do that, with your scheme, you end up with
both nodes named sa-sram at 0.
Which clearly shows that the way you set this unit-address is not
correct: those two devices are mapped at completely different
locations, but you end up with an identical unit address.
I have no idea what is the rule for setting the unit address in this
case, but I'm pretty sure the rule you've chosen is not good.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lee Jones @ 2016-11-10 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110052915.4898-1-lokeshvutla@ti.com>
On Thu, 10 Nov 2016, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Changes since v3:
> - Applied Rob's ack.
> - Sending this patch separately so that this can be merged via Regulator tree.
> - Link to v3: https://patchwork.kernel.org/patch/9408545/
>
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..ae9cf39 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx can be
> + buck0, buck1, ldo0 or ldo1.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
> diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
> index e504b91..70e3df6 100644
> --- a/drivers/regulator/lp873x-regulator.c
> +++ b/drivers/regulator/lp873x-regulator.c
> @@ -24,6 +24,7 @@
> [_id] = { \
> .desc = { \
> .name = _name, \
> + .supply_name = _of "-in", \
> .id = _id, \
> .of_match = of_match_ptr(_of), \
> .regulators_node = of_match_ptr("regulators"),\
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Peter Rosin @ 2016-11-10 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110000923.ltpouekbkx7onzm7@piout.net>
On 2016-11-10 01:09, Alexandre Belloni wrote:
> On 10/11/2016 at 00:41:37 +0100, Peter Rosin wrote :
>> On 2016-10-20 15:35, Alexandre Belloni wrote
>>> On 16/10/2016 at 18:21:45 +0200, Sylvain Rochet wrote :
>>>> Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
>>>> pullup is pointless.
>>>>
>>>> Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
>>>> floating and so consuming a useless extra amount of power in crowbarred
>>>> state if nothing is externally connected to dbgu.
>>> Applied, thanks.
>>
>> I can't seem to find this patch in any of the repos I'm looking at,
>> so I'm wondering where it was applied and when it might hit mainline?
>>
>
> It is applied there:
> http://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=at91-dt
>
> It will land in 4.10. I'll do the PR to arm-soc soon.
Great, thanks! (expected it to be in -next by now and got worried, and
couldn't find it in https://github.com/linux4sam/linux-at91 either...)
Cheers,
Peter
^ permalink raw reply
* [PATCH] mfd: qcom-pm8xxx: Clean up PM8XXX namespace
From: Jacek Anaszewski @ 2016-11-10 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZe0VO=ABfbven8mU0FGb=sJNY_tjk2_GpAP30wsiDkvQ@mail.gmail.com>
On 11/09/2016 11:19 PM, Linus Walleij wrote:
> On Wed, Nov 9, 2016 at 4:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> How many more Acks do we need?
>
> Jacek and one of the ARM SoC people ideally...
>
> Jacek? Arnd/Olof?
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
From: Peter Rosin @ 2016-11-10 7:46 UTC (permalink / raw)
To: linux-arm-kernel
The new size (0x100) also matches the size given in sama5d3.dtsi
Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].
[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
uart0: serial at f0024000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf0024000 0x200>;
+ reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -66,7 +66,7 @@
uart1: serial at f8028000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf8028000 0x200>;
+ reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: kbuild test robot @ 2016-11-10 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
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
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in something not a structure or union
vim +/data +630 drivers/mfd/pm8921-core.c
624 const struct pm8xxx_data *data;
625 int irq, rc;
626 unsigned int val;
627 u32 rev;
628 struct pm_irq_chip *chip;
629
> 630 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
631 if (!data) {
632 dev_err(&pdev->dev, "No matching driver data found\n");
633 return -EINVAL;
---
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/gzip
Size: 30088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/a54a422b/attachment-0001.gz>
^ 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