* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-11-23 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e592169a-6287-7f3c-b4fd-23c4c79198b0@microchip.com>
On Wed, Nov 23, 2016 at 02:34:03PM +0100, Andrei Pistirica wrote:
> From what I understand, your suggestion is:
> (ns | frac) * ppb = (total_ns | total_frac)
> (total_ns | total_frac) / 10^9 = (adj_ns | adj_frac)
> This is correct iff total_ns/10^9 >= 1, but the problem is that there are
> missed fractions due to the following approximation:
> frac*ppb =~ (ns*ppb+frac*ppb*2^16)*2^16-10^9*2^16*flor(ns*ppb+frac*ppb*2^16,
> 10^9).
-ENOPARSE;
> An example which uses values from a real test:
> let ppb=4891, ns=12 and frac=3158
That is a very strange example for nominal frequency. The clock
period is 12.048187255859375 nanoseconds, and so the frequency is
83000037.99 Hz.
But hey, let's go with it...
> - using suggested algorithm, yields: adj_ns = 0 and adj_frac = 0
> - using in-place algorithm, yields: adj_ns = 0, adj_frac = 4
> You can check the calculus.
The test program, below, shows you what I meant. (Of course, you
should adjust this to fit the adjfine() method.)
Unfortunately, this device has a very coarse frequency resolution.
Using a nominal period of ns=12 as an example, the resolution is
2^-16 / 12 or 1.27 ppm. The 24 bit device is much better in this
repect.
The output using your example numbers is:
$ ./a.out 12 3158 4891
ns=12 frac=3158
ns=12 frac=3162
$ ./a.out 12 3158 -4891
ns=12 frac=3158
ns=12 frac=3154
See how you get a result of +/- 4 with just one division?
Thanks,
Richard
---
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
static void adjfreq(uint32_t ns, uint32_t frac, int32_t ppb)
{
uint64_t adj;
uint32_t diff, word;
int neg_adj = 0;
printf("ns=%u frac=%u\n", ns, frac);
if (ppb < 0) {
neg_adj = 1;
ppb = -ppb;
}
word = (ns << 16) + frac;
adj = word;
adj *= ppb;
adj += 500000000UL;
diff = adj / 1000000000UL;
word = neg_adj ? word - diff : word + diff;
printf("ns=%u frac=%u\n", word >> 16, word & 0xffff);
}
int main(int argc, char *argv[])
{
uint32_t ns, frac;
int32_t ppb;
if (argc != 4) {
puts("need ns, frac, and ppb");
return -1;
}
ns = atoi(argv[1]);
frac = atoi(argv[2]);
ppb = atoi(argv[3]);
adjfreq(ns, frac, ppb);
return 0;
}
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-23 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-2uGJGovqQL-gbB54u=fQ9L9YUbDdRo6u3oWqF6znn6Q@mail.gmail.com>
On 20.11.16 17:07:44, Ard Biesheuvel wrote:
> On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
> > The risk of breaking something with my patch is small and limited only
> > to the mapping of efi reserved regions (which is the state of 4.4). If
> > something breaks anyway it can easily be fixed by adding more checks
> > to pfn_valid() as suggested above.
> >
>
> As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
> the correct way to address this. However, doing that does uncover a
> bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
> page fields before the pfn_valid_within() check, so it seems those
> need to be switched around.
>
> Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
> for sparsemem. Care to elaborate why?
HOLES_IN_ZONE is of rare use in the kernel. I think it was introduced
to save memory for the memmap and only some single systems enable it.
There is no architecture that enables it entirely. For good reasons...
It introduces additional checks. pfn_valid() is usually checked only
once for the whole memmap. There are a number of checks enabled, just
grep for pfn_valid_within. This will increase the number of
pfn_valid() calls by a factor of MAX_ORDER_NR_PAGES, in my config this
is 8k. So, this is not the direction to go.
My patch fixes a regression in the kernel that was introduced by the
nomap implementation. Some systems can not boot anymore, beside of
that the BUG_ON() may occur any time depending only on physical page
access, we need to fix 4.9. Here is a reproducer:
https://patchwork.kernel.org/patch/9407677/
My patch also does not break memremap(). With my patch applied
try_ram_remap() would return a linear addr for nomap regions. But this
is only called if WB is explicitly requested, so it should not happen.
If you think pfn_valid() is wrong here, I am happy to send a patch
that fixes this by using page_is_ram(). In any case, the worst case
that may happen is to behave the same as v4.4, we might fix then the
wrong use of pfn_valid() where it is not correctly used to check for
ram.
-Robert
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123205917.GI2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> As requested on irc:
Thanks.
> 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> 7f8: ebfffffe bl 0 <relay_buf_full>
> 7fc: e0844000 add r4, r4, r0
> 800: e300a000 movw sl, #0
> 804: e28b2001 add r2, fp, #1
> 808: e340a000 movt sl, #0
> 80c: e3a01004 mov r1, #4
> 810: e1a0000a mov r0, sl
> 814: ebfffffe bl 0 <_find_next_bit_le>
> 818: e5953000 ldr r3, [r5]
> 81c: e1500003 cmp r0, r3
> 820: e1a0b000 mov fp, r0
> 824: e2802008 add r2, r0, #8
> 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
Okay, so i was 0, so running UP probably isn't going to help. r7 is
also spec_priv->rfs_chan_spec_scan.
So, I think the question is... how is this NULL - and has it always
been NULL...
--
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] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-23 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123211538.GH10776@rric.localdomain>
On 23 November 2016 at 21:15, Robert Richter <robert.richter@cavium.com> wrote:
> On 20.11.16 17:07:44, Ard Biesheuvel wrote:
>> On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
>
>> > The risk of breaking something with my patch is small and limited only
>> > to the mapping of efi reserved regions (which is the state of 4.4). If
>> > something breaks anyway it can easily be fixed by adding more checks
>> > to pfn_valid() as suggested above.
>> >
>>
>> As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
>> the correct way to address this. However, doing that does uncover a
>> bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
>> page fields before the pfn_valid_within() check, so it seems those
>> need to be switched around.
>>
>> Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
>> for sparsemem. Care to elaborate why?
>
> HOLES_IN_ZONE is of rare use in the kernel. I think it was introduced
> to save memory for the memmap and only some single systems enable it.
> There is no architecture that enables it entirely. For good reasons...
>
> It introduces additional checks. pfn_valid() is usually checked only
> once for the whole memmap. There are a number of checks enabled, just
> grep for pfn_valid_within. This will increase the number of
> pfn_valid() calls by a factor of MAX_ORDER_NR_PAGES, in my config this
> is 8k. So, this is not the direction to go.
>
That does sound like a potential issue. But does it cause any slowdown
in practice?
The reality is that CONFIG_HOLES_IN_ZONE perfectly describes the
situation, and so it is still my preferred option if the performance
hit is tolerable.
> My patch fixes a regression in the kernel that was introduced by the
> nomap implementation. Some systems can not boot anymore, beside of
> that the BUG_ON() may occur any time depending only on physical page
> access, we need to fix 4.9. Here is a reproducer:
>
> https://patchwork.kernel.org/patch/9407677/
>
> My patch also does not break memremap(). With my patch applied
> try_ram_remap() would return a linear addr for nomap regions. But this
> is only called if WB is explicitly requested, so it should not happen.
Why? MEMREMAP_WB is used often, among other things for mapping
firmware tables, which are marked as NOMAP, so in these cases, the
linear address is not mapped.
> If you think pfn_valid() is wrong here, I am happy to send a patch
> that fixes this by using page_is_ram(). In any case, the worst case
> that may happen is to behave the same as v4.4, we might fix then the
> wrong use of pfn_valid() where it is not correctly used to check for
> ram.
>
page_is_ram() uses string comparisons to look for regions called
'System RAM'. Is that something we can tolerate for each pfn_valid()
calll?
Perhaps the solution is to reimplement page_is_ram() for arm64 using
memblock_is_memory() instead, But that still means we need to modify
the generic memremap() code first to switch to it before changing the
arm64 implementation of pfn_valid
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123211745.GF14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> > As requested on irc:
>
> Thanks.
>
> > 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> > 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> > 7f8: ebfffffe bl 0 <relay_buf_full>
> > 7fc: e0844000 add r4, r4, r0
> > 800: e300a000 movw sl, #0
> > 804: e28b2001 add r2, fp, #1
> > 808: e340a000 movt sl, #0
> > 80c: e3a01004 mov r1, #4
> > 810: e1a0000a mov r0, sl
> > 814: ebfffffe bl 0 <_find_next_bit_le>
> > 818: e5953000 ldr r3, [r5]
> > 81c: e1500003 cmp r0, r3
> > 820: e1a0b000 mov fp, r0
> > 824: e2802008 add r2, r0, #8
> > 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
>
> Okay, so i was 0, so running UP probably isn't going to help. r7 is
> also spec_priv->rfs_chan_spec_scan.
>
> So, I think the question is... how is this NULL - and has it always
> been NULL...
The problem appears to be that ath_cmn_process_fft() isn't called that
often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
without crashing, I'll gin up a patch.
thx,
Jason.
^ permalink raw reply
* reboot fails on at91sam9g20 with kernel 4.x
From: Alexandre Belloni @ 2016-11-23 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2093786.uQmBVvCouf@ada>
Hi,
On 23/11/2016 at 17:13:05 +0100, Alexander Dahl wrote :
> The last message obviously comes from arch/arm/kernel/reboot.c and
> something fails. ;-)
>
> Searching the web I found someone having a similar problem here:
>
> https://groups.google.com/forum/#!topic/acmesystems/vC_66zmcatk
>
> Reboot works with 3.x kernels (if they run at all). I'll try a 4.1
> tomorrow, but I would be happy if someone could assist me in debugging
> this.
>
Since 3.18, the shdwc and reset controller have their own drivers that
may or may not be compiled in the kernel. Can you check you have
CONFIG_POWER_RESET_AT91_POWEROFF and CONFIG_POWER_RESET_AT91_RESET set
in your configuration? Also, you probably want to check the DT definition
of the shdwc and the rstc.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.10, round 2
From: Kevin Hilman @ 2016-11-23 22:23 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here's a final round of arm64 DT changes for Amlogic family SoCs.
Please pull.
Thanks,
Kevin
The following changes since commit ab5b24fdd2d551ea729e8e19e47811a646260331:
ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes (2016-11-15 12:05:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
for you to fetch changes up to 3db317765fcd55808c782f38c0d3f1862a922c2a:
ARM64: dts: meson-gxl: Add support for Nexbox A95X (2016-11-23 07:57:35 -0800)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.10, round 2
- new SoC support: S912/GXM series (8x A53)
- new boards: Nexbox A1 (S912), Nexbox A95X (S905X)
- resets for 2nd USB PHY
----------------------------------------------------------------
Martin Blumenstingl (1):
ARM64: dts: meson-gxbb: add the USB reset also to the second USB PHY
Neil Armstrong (3):
ARM64: dts: Add support for Meson GXM
ARM64: dts: meson-gxm: Add support for the Nexbox A1
ARM64: dts: meson-gxl: Add support for Nexbox A95X
Documentation/devicetree/bindings/arm/amlogic.txt | 8 +++
arch/arm64/boot/dts/amlogic/Makefile | 4 ++
arch/arm64/boot/dts/amlogic/{meson-gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} | 4 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 77 +++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 58 ++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++++++++++++++++++++++++++++
11 files changed, 643 insertions(+), 3 deletions(-)
rename arch/arm64/boot/dts/amlogic/{meson-gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} (97%)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Kevin Hilman @ 2016-11-23 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e647eb0-2f8a-b46b-2048-7616bfb54ad7@lechnology.com>
David Lechner <david@lechnology.com> writes:
> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>
>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>> controller drivers to da850.dtsi.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> v1 -> v2:
>>>> - moved the priority controller node above the cfgchip node
>>>> - renamed added nodes to better reflect their purpose
>>>>
>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 1bb1f6d..412eec6 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -210,6 +210,10 @@
>>>> };
>>>>
>>>> };
>>>> + prictrl: priority-controller at 14110 {
>>>> + compatible = "ti,da850-mstpri";
>>>> + reg = <0x14110 0x0c>;
>>>
>>>
>>> I think we should add status = "disabled"; here and let boards opt in.
>>>
>>>> + };
>>>> cfgchip: chip-controller at 1417c {
>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>> "simple-mfd";
>>>> reg = <0x1417c 0x14>;
>>>> @@ -451,4 +455,8 @@
>>>> 1 0 0x68000000 0x00008000>;
>>>> status = "disabled";
>>>> };
>>>> + memctrl: memory-controller at b0000000 {
>>>> + compatible = "ti,da850-ddr-controller";
>>>> + reg = <0xb0000000 0xe8>;
>>>
>>>
>>> same here. status = "disabled";
>>>
>>>> + };
>>>> };
>>>>
>>
>> Hi David,
>>
>> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>>
>> FYI this patch has already been queued by Sekhar.
>
> Thanks. I did not see those threads.
>
> FYI to maintainers, having these enabled by default causes error
> messages in the kernel log for other boards that are not supported by
> the drivers.
Then the driver is too noisy and should be cleaned up.
> Since there is only one board that is supported and soon
> to be 2 that are not, I would rather have this disabled by default to
> avoid the error messages.
IMO, what exactly are the error messages? Sounds like the driver is
being too verbose, and calling things errors that are not really errors.
Kevin
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Kevin Hilman @ 2016-11-23 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06bc8517-8c33-85a1-9d5a-29042c7281db@lechnology.com>
David Lechner <david@lechnology.com> writes:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 8945815..1c0224c 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,11 @@
>>> };
>>>
>>> };
>>> + pinconf: pin-controller at 22c00c {
>>> + compatible = "ti,da850-pupd";
>>> + reg = <0x22c00c 0x8>;
>>> + status = "disabled";
>>> + };
>>
>> Can you please place this below the i2c1 node. I am trying to keep the
>> nodes sorted by unit address. I know thats broken in many places today,
>> but lets add the new ones where they should eventually end up.
>
> I can do this, but it seems that the predominant sorting pattern here
> is to keep subsystems together (e.g. all i2c are together, all uart
> are together, etc.)
>
> Would a separate patch to sort everything by unit address to get this
> cleaned up be acceptable?
No thanks. That kind of thing is the needless churn that gets us flamed.
Kevin
^ permalink raw reply
* [GIT PULL] Allwinner clock fixes for 4.9, take 2
From: Stephen Boyd @ 2016-11-23 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122145949.quvtzoupxbxbeql6@lukather>
On 11/22, Maxime Ripard wrote:
> Hi Mike, Stephen,
>
> Here are two new fixes for the 4.9 release.
>
> That should be my final PR for both the 4.9 fixes and 4.10
> developments.
>
> Thanks!
> Maxime
>
> The following changes since commit ac95330b96376550ae7a533d1396272d675adfa2:
>
> clk: sunxi: Fix M factor computation for APB1 (2016-11-04 08:49:46 +0100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-clk-fixes-for-4.9-2
Ok. Pulled into a tag to send off tomorrow with another fix for
v4.9. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-23 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123145916.GL14947@lunn.ch>
Hi Andrew!
On Wed, Nov 23, 2016 at 3:59 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
I do not think so. The ethernet links to the switch are RGMII, not
differential pairs. Differential pair is used only for the eth2 to link
either SFP+ or 88E1514 (via a high-speed switch that selects one or
another). So the problems with differential pairs affect only WAN
interface.
>
>
>> It seems that libphy is probed before pca9538 and we end up with:
>> [ 4.217550] libphy: orion_mdio_bus: probed
>> [ 4.221777] irq: no irq domain found for
>> /soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
>>
>> Any clue where to look in order to defer probing libphy or at least
>> orion_mdio_bus?
>
> I think there is a known phylib problem here. Somewhere in the call
> chain there is a void function, so the EPROBE_DEFFER gets
> discarded. But i could be remembering this wrongly.
Oh yes, I thought that and I tried to find exactly this type of problem
yesterday, but I didn't succeed. But I think that we agreed that we are
going to stick with PHY polling rather then experimenting with
unreliable IRQ over the GPIO expander, so we can leave this unresolved.
I will look into the I2C mux concerns, fix the remaining comments
regarding my version and test RTC more extensively - Uwe's board is
still not ticking, mine does, so we have to rule out that it is a
common problem.
Tomas
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-23 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2bmx5x1y2.fsf@baylibre.com>
On 11/23/2016 04:32 PM, Kevin Hilman wrote:
> David Lechner <david@lechnology.com> writes:
>
>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>
>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>> controller drivers to da850.dtsi.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>> ---
>>>>> v1 -> v2:
>>>>> - moved the priority controller node above the cfgchip node
>>>>> - renamed added nodes to better reflect their purpose
>>>>>
>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>> 1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>>> index 1bb1f6d..412eec6 100644
>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>> @@ -210,6 +210,10 @@
>>>>> };
>>>>>
>>>>> };
>>>>> + prictrl: priority-controller at 14110 {
>>>>> + compatible = "ti,da850-mstpri";
>>>>> + reg = <0x14110 0x0c>;
>>>>
>>>>
>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>
>>>>> + };
>>>>> cfgchip: chip-controller at 1417c {
>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>> "simple-mfd";
>>>>> reg = <0x1417c 0x14>;
>>>>> @@ -451,4 +455,8 @@
>>>>> 1 0 0x68000000 0x00008000>;
>>>>> status = "disabled";
>>>>> };
>>>>> + memctrl: memory-controller at b0000000 {
>>>>> + compatible = "ti,da850-ddr-controller";
>>>>> + reg = <0xb0000000 0xe8>;
>>>>
>>>>
>>>> same here. status = "disabled";
>>>>
>>>>> + };
>>>>> };
>>>>>
>>>
>>> Hi David,
>>>
>>> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>>>
>>> FYI this patch has already been queued by Sekhar.
>>
>> Thanks. I did not see those threads.
>>
>> FYI to maintainers, having these enabled by default causes error
>> messages in the kernel log for other boards that are not supported by
>> the drivers.
>
> Then the driver is too noisy and should be cleaned up.
>
>> Since there is only one board that is supported and soon
>> to be 2 that are not, I would rather have this disabled by default to
>> avoid the error messages.
>
> IMO, what exactly are the error messages? Sounds like the driver is
> being too verbose, and calling things errors that are not really errors.
It is just one line per driver.
dev_err(dev, "no master priorities defined for this board\n");
and
dev_err(dev, "no settings defined for this board\n");
Since "ti,da850-lcdk" is the only board supported in these drivers, all
other boards will see these error messages.
Also, these modules will be loaded and taking up memory on boards that
don't use them. This not really a big deal and they can be explicitly
disabled, so maybe it was not worth mentioning.
>
> Kevin
>
^ permalink raw reply
* [PATCH 2/2] Add support for the Nexbox A1 board based on the Amlogic S912 SoC.
From: Rob Herring @ 2016-11-23 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-3-narmstrong@baylibre.com>
On Mon, Nov 21, 2016 at 05:29:05PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 169 +++++++++++++++++++++
> 3 files changed, 171 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
A few nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 1144214..6ef7c52 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -45,3 +45,4 @@ Board compatible values:
> - "amlogic,p231" (Meson gxl s905d)
> - "amlogic,q200" (Meson gxm s912)
> - "amlogic,q201" (Meson gxm s912)
> + - "nexbox,a1" (Meson gxm s912)
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 7752a16..2fbb8e3 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -10,6 +10,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> new file mode 100644
> index 0000000..d320727
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -0,0 +1,169 @@
> +/*
> + * Copyright (c) 2016 BayLibre, SAS.
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + *
> + * Copyright (c) 2016 Endless Computers, Inc.
> + * Author: Carlo Caione <carlo@endlessm.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-gxm.dtsi"
> +
> +/ {
> + compatible = "nexbox,a1", "amlogic,s912", "amlogic,meson-gxm";
> + model = "NEXBOX A1";
> +
> + aliases {
> + serial0 = &uart_AO;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory at 0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x80000000>;
> + };
> +
> + vddio_boot: regulator-vddio_boot {
Don't use '_' in node names.
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_BOOT";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vddao_3v3: regulator-vddao_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +/* This UART is brought out to the DB9 connector */
> +&uart_AO {
> + status = "okay";
> + pinctrl-0 = <&uart_ao_a_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_input_ao_pins>;
> + pinctrl-names = "default";
> +};
> +
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> +
> +ðmac {
> + status = "okay";
> +
> + pinctrl-0 = <ð_pins>;
> + pinctrl-names = "default";
> +
> + /* Select external PHY by default */
> + phy-handle = <&external_phy>;
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 10000 1000000>;
> + snps,reset-active-low;
> +
> + /* External PHY is in RGMII */
> + phy-mode = "rgmii";
> +};
> +
> +&external_mdio {
> + external_phy: ethernet-phy at 0 {
> + compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +};
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Bjorn Helgaas @ 2016-11-23 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-1-arnd@arndb.de>
On Tue, Nov 22, 2016 at 03:17:51PM +0100, Arnd Bergmann wrote:
> The newly added code to setup the inbound ranges causes a link error
> on 32-bit machines from a 32-bit division:
>
> drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib':
> pcie-iproc.c:(.text.iproc_pcie_setup_ib+0x14c): undefined reference to `__aeabi_uldivmod'
>
> As both sides of the division are always power-of-two numbers and
> we already rely on that, we can use a shift instead.
>
> Fixes: 87c240b19bba ("PCI: iproc: Add inbound DMA mapping support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I folded these fixes into the pci/host-iproc branch for v4.10, thanks!
For some reason, I don't see Ray's responses on the list. Maybe still
some email problem?
> ---
> drivers/pci/host/pcie-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index d10e6aa32e0d..857ff5198317 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -865,7 +865,7 @@ static int iproc_pcie_ib_write(struct iproc_pcie *pcie, int region_idx,
> * Now program the IMAP registers. Each IARR region may have one or
> * more IMAP windows.
> */
> - size /= nr_windows;
> + size >>= ilog2(nr_windows);
> for (window_idx = 0; window_idx < nr_windows; window_idx++) {
> val = readl(pcie->base + imap_offset);
> val |= lower_32_bits(axi_addr) | IMAP_VALID;
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-23 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121213052.8684-2-afd@ti.com>
On Mon, Nov 21, 2016 at 03:30:51PM -0600, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna at ti.com: revise the binding format]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 66 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-cm-fx6: enable S/PDIF support
From: Fabio Estevam @ 2016-11-23 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5da612fbab7a4064993790702550fa77@rwthex-s1-b.rwth-ad.de>
On Tue, Nov 22, 2016 at 10:07 PM, <christopher.spinrath@rwth-aachen.de> wrote:
> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> Enable the S/PDIF transceiver present on the cm-fx6 module.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2] ARM: dts: AM571x-IDK Initial Support
From: Rob Herring @ 2016-11-23 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122041732.8385-1-lokeshvutla@ti.com>
On Tue, Nov 22, 2016 at 09:47:32AM +0530, Lokesh Vutla wrote:
> From: Schuyler Patton <spatton@ti.com>
>
> The AM571x-IDK board is a board based on TI's AM5718 SOC
> which has a single core 1.5GHz A15 processor. This board is a
> development platform for the Industrial market with:
> - 1GB of DDR3L
> - Dual 1Gbps Ethernet
> - HDMI,
> - PRU-ICSS
> - uSD
> - 16GB eMMC
> - CAN
> - RS-485
> - PCIe
> - USB3.0
> - Video Input Port
> - Industrial IO port and expansion connector
>
> The link to the data sheet and TRM can be found here:
>
> http://www.ti.com/product/AM5718
>
> Initial support is only for basic peripherals.
>
> Signed-off-by: Schuyler Patton <spatton@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Cahnges since v1:
> - Dropped "ti,dra722", and "ti,dra72" from compatibles
> - Fixes few node names as suggested by Rob.
> Logs: http://pastebin.ubuntu.com/23515001/
>
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am571x-idk.dts | 81 ++++++++++++++++++++++
> 3 files changed, 85 insertions(+)
> create mode 100644 arch/arm/boot/dts/am571x-idk.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment
From: Fabio Estevam @ 2016-11-23 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123004204.10851-1-stefan@agner.ch>
On Tue, Nov 22, 2016 at 10:42 PM, Stefan Agner <stefan@agner.ch> wrote:
> The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
> separately:
>
> Clock Clock Root Description
> apb_clk MAIN_AXI_CLK_ROOT AXI clock
> pix_clk LCDIF_PIXEL_CLK_ROOT Pixel clock
> ipg_clk_s MAIN_AXI_CLK_ROOT Peripheral access clock
>
> All of them are switched by a single gate, which is part of the
> IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
> the AXI bus clock (clock-name "axi") makes sure the gate gets
> enabled when accessing registers.
>
> There seem to be no separate AXI display clock, and the clock is
> optional. Hence remove the dummy clock.
>
> This fixes kernel freezes when starting the X-Server (which
> disables/re-enables the display controller).
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 4/6] dt-bindings: change hi6220-reset.txt according to reset-hi6220.c
From: Rob Herring @ 2016-11-23 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2314383.qiZ3Cq7QsP@wuerfel>
On Tue, Nov 22, 2016 at 09:48:32AM +0100, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 3:49:19 PM CET Zhangfei Gao wrote:
> > Required properties:
> > - compatible: should be one of the following:
> > - - "hisilicon,hi6220-sysctrl", "syscon" : For peripheral reset controller.
> > - - "hisilicon,hi6220-mediactrl", "syscon" : For media reset controller.
> > -- reg: should be register base and length as documented in the
> > - datasheet
> > + - "hisilicon,hi6220-reset-sysctrl" : For peripheral reset controller.
> > + - "hisilicon,hi6220-reset-mediactrl" : For media reset controller.
> > +- hisi,rst-syscon: phandle of the reset's syscon.
> > - #reset-cells: 1, see below
> >
>
> Please keep the old strings around for compatibility.
Why are these even changing? The commit message should say why.
Rob
^ permalink raw reply
* [PATCH 1/4] clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend
From: Rob Herring @ 2016-11-23 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479807866-6957-1-git-send-email-daniel.lezcano@linaro.org>
On Tue, Nov 22, 2016 at 10:44:21AM +0100, Daniel Lezcano wrote:
> From: Brian Norris <briannorris@chromium.org>
>
> The ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 5 +++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clocksource/arm_arch_timer.c | 9 ++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata
From: Sebastian Reichel @ 2016-11-23 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-7-git-send-email-robert.jarzmik@free.fr>
Hi Robert,
On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote:
> As the power supply framework provides a way to store and retrieve
> private supply data, use it.
>
> In the process, change the platform data for wm97xx_battery from a
> container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/input/touchscreen/wm97xx-core.c | 2 +-
> drivers/power/supply/wm97xx_battery.c | 25 ++++++++++---------------
> 2 files changed, 11 insertions(+), 16 deletions(-)
I queued this into power-supply's for-next branch.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/37574d6b/attachment.sig>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-23 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2168980.T3HadihU3R@wuerfel>
On Wednesday, November 23, 2016 6:07:11 PM CET Arnd Bergmann wrote:
> On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
>
> Please don't proliferate the use of
> pci_pio_to_address/pci_address_to_pio here, computing the physical
> address from the logical address is trivial, you just need to
> subtract the start of the range that you already use when matching
> the port number range.
>
> The only thing we need here is to make of_address_to_resource()
> return the correct logical port number that was registered for
> a given host device when asked to translate an address that
> does not have a CPU address associated with it.
Ok, I admit this was a little harder than I expected, but see below
for a rough outline of how I think it can be done.
This makes it possible to translate bus specific I/O port numbers
from device nodes into Linux port numbers, and gives a way to register
them. We could take this further and completely remove pci_pio_to_address
and pci_address_to_pio if we make the I/O port translation always
go through the io_range list, looking up up the hostbridge by fwnode,
but we don't have to do that now.
The patch is completely untested and probably buggy, it just seemed
easier to put out a prototype than to keep going in circles with the
discussion.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index bf601d4df8cf..6cadf0501bb0 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct device *dev,
}
}
-static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
+static void acpi_pci_root_remap_iospace(struct fwnode_handle *node,
+ struct resource_entry *entry)
{
#ifdef PCI_IOBASE
struct resource *res = entry->res;
@@ -739,11 +740,7 @@ static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
resource_size_t length = resource_size(res);
unsigned long port;
- if (pci_register_io_range(cpu_addr, length))
- goto err;
-
- port = pci_address_to_pio(cpu_addr);
- if (port == (unsigned long)-1)
+ if (pci_register_io_range(node, cpu_addr, length, &port))
goto err;
res->start = port;
@@ -781,7 +778,8 @@ int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
else {
resource_list_for_each_entry_safe(entry, tmp, list) {
if (entry->res->flags & IORESOURCE_IO)
- acpi_pci_root_remap_iospace(entry);
+ acpi_pci_root_remap_iospace(&device->fwnode,
+ entry);
if (entry->res->flags & IORESOURCE_DISABLED)
resource_list_destroy_entry(entry);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index a50025a3777f..df96955a43f8 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -760,8 +760,10 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
set_bit(NBD_RUNNING, &nbd->runtime_flags);
blk_mq_update_nr_hw_queues(&nbd->tag_set, nbd->num_connections);
args = kcalloc(num_connections, sizeof(*args), GFP_KERNEL);
- if (!args)
+ if (!args) {
+ error = -ENOMEM;
goto out_err;
+ }
nbd->task_recv = current;
mutex_unlock(&nbd->config_lock);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903fe9d2..5decaba96eed 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -2,6 +2,7 @@
#define pr_fmt(fmt) "OF: " fmt
#include <linux/device.h>
+#include <linux/fwnode.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/module.h>
@@ -323,14 +324,9 @@ int of_pci_range_to_resource(struct of_pci_range *range,
if (res->flags & IORESOURCE_IO) {
unsigned long port;
- err = pci_register_io_range(range->cpu_addr, range->size);
+ err = pci_register_io_range(&np->fwnode, range->cpu_addr, range->size, &port);
if (err)
goto invalid_range;
- port = pci_address_to_pio(range->cpu_addr);
- if (port == (unsigned long)-1) {
- err = -EINVAL;
- goto invalid_range;
- }
res->start = port;
} else {
if ((sizeof(resource_size_t) < 8) &&
@@ -479,7 +475,7 @@ static int of_empty_ranges_quirk(struct device_node *np)
return false;
}
-static int of_translate_one(struct device_node *parent, struct of_bus *bus,
+static u64 of_translate_one(struct device_node *parent, struct of_bus *bus,
struct of_bus *pbus, __be32 *addr,
int na, int ns, int pna, const char *rprop)
{
@@ -507,7 +503,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
ranges = of_get_property(parent, rprop, &rlen);
if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
pr_debug("no ranges; cannot translate\n");
- return 1;
+ return OF_BAD_ADDR;
}
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
@@ -528,7 +524,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
}
if (offset == OF_BAD_ADDR) {
pr_debug("not found !\n");
- return 1;
+ return offset;
}
memcpy(addr, ranges + na, 4 * pna);
@@ -537,7 +533,10 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
pr_debug("with offset: %llx\n", (unsigned long long)offset);
/* Translate it into parent bus space */
- return pbus->translate(addr, offset, pna);
+ if (pbus->translate(addr, offset, pna))
+ return OF_BAD_ADDR;
+
+ return offset;
}
/*
@@ -549,9 +548,14 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
* that translation is impossible (that is we are not dealing with a value
* that can be mapped to a cpu physical address). This is not really specified
* that way, but this is traditionally the way IBM at least do things
+ *
+ * Whenever the translation fails, the *host pointer will be set to the
+ * device that lacks a tranlation, and the return code is relative to
+ * that node.
*/
static u64 __of_translate_address(struct device_node *dev,
- const __be32 *in_addr, const char *rprop)
+ const __be32 *in_addr, const char *rprop,
+ struct device_node **host)
{
struct device_node *parent = NULL;
struct of_bus *bus, *pbus;
@@ -564,6 +568,7 @@ static u64 __of_translate_address(struct device_node *dev,
/* Increase refcount at current level */
of_node_get(dev);
+ *host = NULL;
/* Get parent & match bus type */
parent = of_get_parent(dev);
if (parent == NULL)
@@ -600,8 +605,9 @@ static u64 __of_translate_address(struct device_node *dev,
pbus = of_match_bus(parent);
pbus->count_cells(dev, &pna, &pns);
if (!OF_CHECK_COUNTS(pna, pns)) {
- pr_err("Bad cell count for %s\n",
- of_node_full_name(dev));
+ pr_debug("Bad cell count for %s\n",
+ of_node_full_name(dev));
+ *host = of_node_get(parent);
break;
}
@@ -609,7 +615,9 @@ static u64 __of_translate_address(struct device_node *dev,
pbus->name, pna, pns, of_node_full_name(parent));
/* Apply bus translation */
- if (of_translate_one(dev, bus, pbus, addr, na, ns, pna, rprop))
+ result = of_translate_one(dev, bus, pbus, addr, na, ns,
+ pna, rprop);
+ if (result == OF_BAD_ADDR)
break;
/* Complete the move up one level */
@@ -628,13 +636,32 @@ static u64 __of_translate_address(struct device_node *dev,
u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
{
- return __of_translate_address(dev, in_addr, "ranges");
+ struct device_node *host;
+ u64 ret;
+
+ ret = __of_translate_address(dev, in_addr, "ranges", &host);
+ if (host) {
+ of_node_put(host);
+ return OF_BAD_ADDR;
+ }
+
+ return ret;
}
EXPORT_SYMBOL(of_translate_address);
u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
{
- return __of_translate_address(dev, in_addr, "dma-ranges");
+ struct device_node *host;
+ u64 ret;
+
+ ret = __of_translate_address(dev, in_addr, "dma-ranges", &host);
+
+ if (host) {
+ of_node_put(host);
+ return OF_BAD_ADDR;
+ }
+
+ return ret;
}
EXPORT_SYMBOL(of_translate_dma_address);
@@ -676,29 +703,48 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
}
EXPORT_SYMBOL(of_get_address);
+extern unsigned long extio_translate(struct fwnode_handle *node, unsigned long offset);
+
+u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr)
+{
+ u64 taddr;
+ unsigned long port;
+ struct device_node *host;
+
+ taddr = __of_translate_address(dev, in_addr, "ranges", &host);
+ if (host) {
+ /* host specific port access */
+ port = extio_translate(&host->fwnode, taddr);
+ of_node_put(host);
+ } else {
+ /* memory mapped I/O range */
+ port = pci_address_to_pio(taddr);
+ if (port == (unsigned long)-1)
+ return OF_BAD_ADDR;
+ }
+
+ return port;
+}
+
static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
const char *name, struct resource *r)
{
u64 taddr;
- if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
+ if (flags & IORESOURCE_MEM)
+ taddr = of_translate_address(dev, addrp);
+ else if (flags & IORESOURCE_IO)
+ taddr = of_translate_ioport(dev, addrp);
+ else
return -EINVAL;
- taddr = of_translate_address(dev, addrp);
+
if (taddr == OF_BAD_ADDR)
return -EINVAL;
memset(r, 0, sizeof(struct resource));
- if (flags & IORESOURCE_IO) {
- unsigned long port;
- port = pci_address_to_pio(taddr);
- if (port == (unsigned long)-1)
- return -EINVAL;
- r->start = port;
- r->end = port + size - 1;
- } else {
- r->start = taddr;
- r->end = taddr + size - 1;
- }
+
+ r->start = taddr;
+ r->end = taddr + size - 1;
r->flags = flags;
r->name = name ? name : dev->full_name;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index eda6a7cf0e54..320ab9fbf6af 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3249,6 +3249,7 @@ EXPORT_SYMBOL(pci_request_regions_exclusive);
#ifdef PCI_IOBASE
struct io_range {
struct list_head list;
+ struct fwnode_handle *node;
phys_addr_t start;
resource_size_t size;
};
@@ -3257,11 +3258,14 @@ static LIST_HEAD(io_range_list);
static DEFINE_SPINLOCK(io_range_lock);
#endif
+#define IO_RANGE_IOEXT (resource_size_t)(-1ull)
+
/*
* Record the PCI IO range (expressed as CPU physical address + size).
* Return a negative value if an error has occured, zero otherwise
*/
-int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+int __weak pci_register_io_range(struct fwnode_handle *node, phys_addr_t addr,
+ resource_size_t size, unsigned long *port)
{
int err = 0;
@@ -3272,7 +3276,12 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
/* check if the range hasn't been previously recorded */
spin_lock(&io_range_lock);
list_for_each_entry(range, &io_range_list, list) {
- if (addr >= range->start && addr + size <= range->start + size) {
+ if (node == range->node)
+ goto end_register;
+
+ if (addr != IO_RANGE_IOEXT &&
+ addr >= range->start &&
+ addr + size <= range->start + size) {
/* range already registered, bail out */
goto end_register;
}
@@ -3298,6 +3307,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
goto end_register;
}
+ range->node = node;
range->start = addr;
range->size = size;
@@ -3305,11 +3315,26 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
end_register:
spin_unlock(&io_range_lock);
+
+ *port = allocated_size;
+#else
+ /*
+ * powerpc and microblaze have their own registration,
+ * just look up the value here
+ */
+ *port = pci_address_to_pio(addr);
#endif
return err;
}
+#ifdef CONFIG_IOEXT
+int ioext_register_io_range
+{
+ return pci_register_io_range(node, IO_RANGE_IOEXT, size, port);
+}
+#endif
+
phys_addr_t pci_pio_to_address(unsigned long pio)
{
phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6bd94a803e8f..b7a8fa3da3ca 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1192,7 +1192,8 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
void *alignf_data);
-int pci_register_io_range(phys_addr_t addr, resource_size_t size);
+int pci_register_io_range(struct fwnode_handle *node, phys_addr_t addr,
+ resource_size_t size, unsigned long *port);
unsigned long pci_address_to_pio(phys_addr_t addr);
phys_addr_t pci_pio_to_address(unsigned long pio);
int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
^ permalink raw reply related
* [PATCH RESEND 2/2] gpio: axp209: add pinctrl support
From: kbuild test robot @ 2016-11-24 0:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123141151.25315-3-quentin.schulz@free-electrons.com>
Hi Quentin,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.9-rc6 next-20161123]
[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/Quentin-Schulz/add-support-for-AXP209-GPIOs-functions/20161124-061409
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
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=tile
All errors (new ones prefixed by >>):
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_get_direction':
drivers/gpio/gpio-axp209.c:131:49: error: request for member 'drv_data' in something not a structure or union
drivers/gpio/gpio-axp209.c:131:16: warning: cast from pointer to integer of different size
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_set':
drivers/gpio/gpio-axp209.c:158:49: error: request for member 'drv_data' in something not a structure or union
drivers/gpio/gpio-axp209.c:158:16: warning: cast from pointer to integer of different size
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_input':
drivers/gpio/gpio-axp209.c:168:2: error: implicit declaration of function 'pinctrl_gpio_direction_input'
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set':
drivers/gpio/gpio-axp209.c:182:9: error: implicit declaration of function 'pinctrl_dev_get_drvdata'
drivers/gpio/gpio-axp209.c:182:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c:183:49: error: request for member 'drv_data' in something not a structure or union
drivers/gpio/gpio-axp209.c:183:16: warning: cast from pointer to integer of different size
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_cnt':
drivers/gpio/gpio-axp209.c:191:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_name':
drivers/gpio/gpio-axp209.c:199:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_groups':
drivers/gpio/gpio-axp209.c:209:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pinctrl_desc_find_func_by_name':
drivers/gpio/gpio-axp209.c:228:23: error: request for member 'name' in something not a structure or union
drivers/gpio/gpio-axp209.c:228:3: warning: passing argument 1 of 'strcmp' from incompatible pointer type [enabled by default]
include/linux/string.h:42:12: note: expected 'const char but argument is of type 'const struct axp20x_desc_pin
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set_mux':
drivers/gpio/gpio-axp209.c:253:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pctl_desc_find_func_by_pin':
drivers/gpio/gpio-axp209.c:276:15: error: request for member 'number' in something not a structure or union
drivers/gpio/gpio-axp209.c:276:23: warning: comparison between pointer and integer [enabled by default]
drivers/gpio/gpio-axp209.c: At top level:
drivers/gpio/gpio-axp209.c:293:7: warning: 'struct pinctrl_gpio_range' declared inside parameter list [enabled by default]
drivers/gpio/gpio-axp209.c:293:7: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_gpio_set_direction':
drivers/gpio/gpio-axp209.c:295:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: At top level:
drivers/gpio/gpio-axp209.c:311:21: error: variable 'axp20x_pmx_ops' has initializer but incomplete type
drivers/gpio/gpio-axp209.c:312:2: error: unknown field 'get_functions_count' specified in initializer
drivers/gpio/gpio-axp209.c:312:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:312:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:313:2: error: unknown field 'get_function_name' specified in initializer
drivers/gpio/gpio-axp209.c:313:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:313:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:314:2: error: unknown field 'get_function_groups' specified in initializer
drivers/gpio/gpio-axp209.c:314:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:314:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:315:2: error: unknown field 'set_mux' specified in initializer
drivers/gpio/gpio-axp209.c:315:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:315:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:316:2: error: unknown field 'gpio_set_direction' specified in initializer
drivers/gpio/gpio-axp209.c:316:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:316:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:317:2: error: unknown field 'strict' specified in initializer
drivers/gpio/gpio-axp209.c:317:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:317:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_groups_cnt':
drivers/gpio/gpio-axp209.c:322:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_group_pins':
drivers/gpio/gpio-axp209.c:330:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_group_name':
drivers/gpio/gpio-axp209.c:342:29: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: At top level:
drivers/gpio/gpio-axp209.c:347:21: error: variable 'axp20x_pctrl_ops' has initializer but incomplete type
drivers/gpio/gpio-axp209.c:348:2: error: unknown field 'dt_node_to_map' specified in initializer
drivers/gpio/gpio-axp209.c:348:21: error: 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function)
drivers/gpio/gpio-axp209.c:348:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:348:2: warning: (near initialization for 'axp20x_pctrl_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:349:2: error: unknown field 'dt_free_map' specified in initializer
drivers/gpio/gpio-axp209.c:349:18: error: 'pinconf_generic_dt_free_map' undeclared here (not in a function)
drivers/gpio/gpio-axp209.c:349:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:349:2: warning: (near initialization for 'axp20x_pctrl_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:350:2: error: unknown field 'get_groups_count' specified in initializer
drivers/gpio/gpio-axp209.c:350:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:350:2: warning: (near initialization for 'axp20x_pctrl_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:351:2: error: unknown field 'get_group_name' specified in initializer
drivers/gpio/gpio-axp209.c:351:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:351:2: warning: (near initialization for 'axp20x_pctrl_ops') [enabled by default]
drivers/gpio/gpio-axp209.c:352:2: error: unknown field 'get_group_pins' specified in initializer
drivers/gpio/gpio-axp209.c:352:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:352:2: warning: (near initialization for 'axp20x_pctrl_ops') [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_attach_group_function':
drivers/gpio/gpio-axp209.c:416:23: error: request for member 'name' in something not a structure or union
drivers/gpio/gpio-axp209.c:416:13: warning: assignment from incompatible pointer type [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_build_state':
drivers/gpio/gpio-axp209.c:439:49: error: request for member 'name' in something not a structure or union
drivers/gpio/gpio-axp209.c:439:24: warning: assignment from incompatible pointer type [enabled by default]
drivers/gpio/gpio-axp209.c:440:48: error: request for member 'number' in something not a structure or union
drivers/gpio/gpio-axp209.c:440:23: warning: assignment makes integer from pointer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pctl_probe':
drivers/gpio/gpio-axp209.c:522:61: error: dereferencing pointer to incomplete type
>> drivers/gpio/gpio-axp209.c:522:52: error: invalid operands to binary Makefile arch drivers include kernel scripts source (have 'int' and 'const struct axp20x_desc_pin
drivers/gpio/gpio-axp209.c:523:8: warning: passing argument 2 of 'devm_kzalloc' makes integer from pointer without a cast [enabled by default]
include/linux/device.h:658:21: note: expected 'size_t' but argument is of type 'const struct axp20x_desc_pin
drivers/gpio/gpio-axp209.c:528:3: error: invalid use of undefined type 'struct pinctrl_pin_desc'
drivers/gpio/gpio-axp209.c:528:7: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:528:3: warning: statement with no effect
drivers/gpio/gpio-axp209.c:530:47: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:530:2: warning: passing argument 2 of 'devm_kzalloc' makes integer from pointer without a cast [enabled by default]
include/linux/device.h:658:21: note: expected 'size_t' but argument is of type 'const struct axp20x_desc_pin
drivers/gpio/gpio-axp209.c:534:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:534:12: error: request for member 'name' in something not a structure or union
drivers/gpio/gpio-axp209.c:534:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:535:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:535:12: error: request for member 'owner' in something not a structure or union
drivers/gpio/gpio-axp209.c:535:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:536:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:536:12: error: request for member 'pins' in something not a structure or union
drivers/gpio/gpio-axp209.c:536:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:537:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:537:12: error: request for member 'npins' in something not a structure or union
drivers/gpio/gpio-axp209.c:537:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:538:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:538:12: error: request for member 'pctlops' in something not a structure or union
drivers/gpio/gpio-axp209.c:538:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:539:12: error: dereferencing pointer to incomplete type
drivers/gpio/gpio-axp209.c:539:12: error: request for member 'pmxops' in something not a structure or union
drivers/gpio/gpio-axp209.c:539:2: warning: statement with no effect
drivers/gpio/gpio-axp209.c:541:2: error: implicit declaration of function 'devm_pinctrl_register'
drivers/gpio/gpio-axp209.c:541:17: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/gpio/gpio-axp209.c:557:19: error: request for member 'number' in something not a structure or union
drivers/gpio/gpio-axp209.c:557:36: error: request for member 'number' in something not a structure or union
drivers/gpio/gpio-axp209.c:558:11: warning: passing argument 3 of 'gpiochip_add_pin_range' makes integer from pointer without a cast [enabled by default]
include/linux/gpio/driver.h:324:1: note: expected 'unsigned int' but argument is of type 'const struct axp20x_desc_pin
drivers/gpio/gpio-axp209.c:558:11: warning: passing argument 4 of 'gpiochip_add_pin_range' makes integer from pointer without a cast [enabled by default]
include/linux/gpio/driver.h:324:1: note: expected 'unsigned int' but argument is of type 'const struct axp20x_desc_pin
cc1: some warnings being treated as errors
vim +522 drivers/gpio/gpio-axp209.c
410 }
411
412 func_grp = func->groups;
413 while (*func_grp)
414 func_grp++;
415
> 416 *func_grp = pin->pin.name;
417 desc_func++;
418 }
419
420 return 0;
421 }
422
423 static int axp20x_build_state(struct platform_device *pdev)
424 {
425 struct axp20x_pctl *pctl = platform_get_drvdata(pdev);
426 unsigned int npins = pctl->desc->npins;
427 const struct axp20x_desc_pin *pin;
428 struct axp20x_desc_function *func;
429 int i, ret;
430
431 pctl->ngroups = npins;
432 pctl->groups = devm_kzalloc(&pdev->dev,
433 pctl->ngroups * sizeof(*pctl->groups),
434 GFP_KERNEL);
435 if (!pctl->groups)
436 return -ENOMEM;
437
438 for (i = 0; i < npins; i++) {
439 pctl->groups[i].name = pctl->desc->pins[i].pin.name;
440 pctl->groups[i].pin = pctl->desc->pins[i].pin.number;
441 }
442
443 /* We assume 4 functions per pin should be enough as a default max */
444 pctl->functions = devm_kzalloc(&pdev->dev,
445 npins * 4 * sizeof(*pctl->functions),
446 GFP_KERNEL);
447 if (!pctl->functions)
448 return -ENOMEM;
449
450 /* Create a list of uniquely named functions */
451 for (i = 0; i < npins; i++) {
452 pin = &pctl->desc->pins[i];
453 func = pin->functions;
454
455 while (func->name) {
456 axp20x_pinctrl_add_function(pctl, func->name);
457 func++;
458 }
459 }
460
461 pctl->functions = krealloc(pctl->functions,
462 pctl->nfunctions * sizeof(*pctl->functions),
463 GFP_KERNEL);
464
465 for (i = 0; i < npins; i++) {
466 pin = &pctl->desc->pins[i];
467 ret = axp20x_attach_group_function(pdev, pin);
468 if (ret)
469 return ret;
470 }
471
472 return 0;
473 }
474
475 static int axp20x_pctl_probe(struct platform_device *pdev)
476 {
477 struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
478 const struct axp20x_desc_pin *pin;
479 struct axp20x_pctl *pctl;
480 struct pinctrl_desc *pctrl_desc;
481 struct pinctrl_pin_desc *pins;
482 int ret, i;
483
484 if (!of_device_is_available(pdev->dev.of_node))
485 return -ENODEV;
486
487 if (!axp20x) {
488 dev_err(&pdev->dev, "Parent drvdata not set\n");
489 return -EINVAL;
490 }
491
492 pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
493 if (!pctl)
494 return -ENOMEM;
495
496 pctl->chip.base = -1;
497 pctl->chip.can_sleep = true;
498 pctl->chip.request = gpiochip_generic_request;
499 pctl->chip.free = gpiochip_generic_free;
500 pctl->chip.parent = &pdev->dev;
501 pctl->chip.label = dev_name(&pdev->dev);
502 pctl->chip.owner = THIS_MODULE;
503 pctl->chip.get = axp20x_gpio_get;
504 pctl->chip.get_direction = axp20x_gpio_get_direction;
505 pctl->chip.set = axp20x_gpio_set;
506 pctl->chip.direction_input = axp20x_gpio_input;
507 pctl->chip.direction_output = axp20x_gpio_output;
508 pctl->chip.ngpio = 3;
509 pctl->chip.can_sleep = true;
510
511 pctl->regmap = axp20x->regmap;
512
513 pctl->desc = &axp20x_pinctrl_data;
514 pctl->dev = &pdev->dev;
515
516 platform_set_drvdata(pdev, pctl);
517
518 ret = axp20x_build_state(pdev);
519 if (ret)
520 return ret;
521
> 522 pins = devm_kzalloc(&pdev->dev, pctl->desc->npins * sizeof(*pins),
523 GFP_KERNEL);
524 if (!pins)
525 return -ENOMEM;
---
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: 46296 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/f51c9ead/attachment-0001.gz>
^ permalink raw reply
* [PATCH 2/2] clk: uniphier: add clock data for cpufreq
From: Stephen Boyd @ 2016-11-24 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503088-26508-2-git-send-email-yamada.masahiro@socionext.com>
On 10/27, Masahiro Yamada wrote:
> Data needed for CPU-gear change (cpufreq).
>
> Note:
> At this moment, some clock data for Pro5/Pxs2 (32bit SoCs) are
> a bit faked because clock rates greater than LONG_MAX (~2.15 GHz)
> must be avoided on 32 bit systems.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> I raised a flag in the following post:
> https://www.spinics.net/lists/kernel/msg2361374.html
>
> I have not had any comments.
> Anyway, I am moving forward.
> I can fix the data arrays to reflect the real
> clock topology.
>
>
> drivers/clk/uniphier/clk-uniphier-sys.c | 111 ++++++++++++++++++++++++++++++++
> drivers/clk/uniphier/clk-uniphier.h | 35 +++++++++-
> 2 files changed, 145 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
> index 5d02999..74ab179 100644
> --- a/drivers/clk/uniphier/clk-uniphier-sys.c
> +++ b/drivers/clk/uniphier/clk-uniphier-sys.c
> @@ -41,6 +41,19 @@
> #define UNIPHIER_PRO4_SYS_CLK_USB3(idx, ch) \
> UNIPHIER_CLK_GATE("usb3" #ch, (idx), NULL, 0x2104, 16 + (ch))
>
> +#define UNIPHIER_PRO5_SYS_CPUGEARS \
> + UNIPHIER_CLK_DIV8("cpll", 2, 3, 4, 6, 8, 12, 16, 24), \
> + UNIPHIER_CLK_DIV8("spll", 2, 3, 4, 6, 8, 12, 16, 24), \
> + UNIPHIER_CLK_DIV8("ippll", 2, 3, 4, 6, 8, 12, 16, 24), \
> + UNIPHIER_CLK_CPUGEAR("cpu-ca9", 32, 0x8000, 0x1f, 16, \
> + "cpll/2", "spll/2", "cpll/3", "spll/3", \
> + "cpll/4", "spll/4", "cpll/6", "spll/6", \
> + "cpll/8", "spll/8", "cpll/12", "spll/12", \
> + "cpll/16", "spll/16", "cpll/24", "spll/24"),\
> + UNIPHIER_CLK_CPUGEAR("cpu-ipp", 34, 0x8100, 0xf, 8, \
> + "ippll/2", "spll/2", "ippll/3", "spll/3", \
> + "spll/4", "spll/8", "ippll/4", "ippll/8")
> +
> const struct uniphier_clk_data uniphier_sld3_sys_clk_data[] = {
> UNIPHIER_CLK_FACTOR("spll", -1, "ref", 65, 1), /* 1597.44 MHz */
> UNIPHIER_CLK_FACTOR("upll", -1, "ref", 6000, 512), /* 288 MHz */
> @@ -96,6 +109,8 @@
> };
>
> const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] = {
> + UNIPHIER_CLK_FACTOR("cpll", -1, "ref", 140, 1), /* 2800 MHz */
> + UNIPHIER_CLK_FACTOR("ippll", -1, "ref", 130, 1), /* 2600 MHz */
> UNIPHIER_CLK_FACTOR("spll", -1, "ref", 120, 1), /* 2400 MHz */
> UNIPHIER_CLK_FACTOR("dapll1", -1, "ref", 128, 1), /* 2560 MHz */
> UNIPHIER_CLK_FACTOR("dapll2", -1, "ref", 144, 125), /* 2949.12 MHz */
> @@ -106,10 +121,43 @@
> UNIPHIER_PRO4_SYS_CLK_GIO(12), /* PCIe, USB3 */
> UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
> UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
> +#if 1
> + /*
> + * TODO:
> + * The return type of .round_rate() is "long", which is 32 bit wide on
> + * 32 bit systems. Clock rate greater than LONG_MAX (~ 2.15 GHz) is
> + * treated as an error. Needs a workaround until the problem is fixed.
> + */
Just curious is the problem internal to the clk framework because
of the clk_ops::round_rate design? Or does the consumer, cpufreq
in this case, have to deal with rates that are larger than
unsigned long on a 32 bit system? If it's just a clk_ops problem
and we need to support rates up to 32 bits wide (~ 4.3 GHz) on
the system then the driver could be changed to use
.determine_rate() ops and that would allow us to use all the bits
of unsigned long to figure out rates.
If the problem is rates even larger than unsigned long on 32 bit
systems, then at the least I'd like to see some sort of plan to
fix that in the framework before merging code. Hopefully it can
be done gradually, but as I start looking at it it seems more and
more complicated to support this so this will be a long term
project.
We can discuss the clk API changes needed as well if those are
required, but that is another issue that requires changes in
other places outside of clk drivers.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-11-24 0:18 UTC (permalink / raw)
To: linux-arm-kernel
I observed the following "strange" value when trying to read the SCPI
temperature sensor on my Amlogic GXM S912 device:
$ cat /sys/class/hwmon/hwmon0/temp1_input
6875990994467160116
The value reported by the original kernel (Amlogic vendor kernel, after
a reboot obviously) was 53C.
The Amlogic SCPI driver only uses a single 32bit value to read the
sensor value, instead of two. After stripping the upper 32bits from
above value gives "52" as result, which is basically identical to
what the vendor kernel reports.
I also compared this with the value shown by u-boot (since there's
less delay between "reboot to u-boot" compared to "reboot from mainline
kernel to vendor kernel") and the temperature reported by u-boot always
matches the lower 32bits of the value from scpi-hwmon temp1_input.
This patch introduces a separate function for reading the sensor value
on pre-v1.0 SCPI firmwares. I also tried initializing the "buf"
variable in scpi_sensor_get_value() but this didn't work (because we
request a 64bit payload from the SCPI firmware, but the firmware only
replies with a 32bit payload).
Martin Blumenstingl (1):
firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI
firmwares
drivers/firmware/arm_scpi.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--
2.10.2
^ 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