* [PATCH RFC 00/12] tda998x updates
From: Russell King - ARM Linux @ 2016-11-08 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <624786c1-0d55-8ab6-2db0-0497248201ca@arm.com>
On Tue, Nov 08, 2016 at 03:25:45PM +0000, Robin Murphy wrote:
> On 08/11/16 13:34, Russell King - ARM Linux wrote:
> > On Tue, Nov 08, 2016 at 01:32:15PM +0000, Russell King - ARM Linux wrote:
> >> Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> >> these patches it's the original set of 10 patches. I've not pushed
> >> these ones out to that branch yet, as I've three additional patches on
> >> top of these which aren't "ready" for pushing out.
> >
> > Here's the delta between the branch and what I just posted:
>
> Great, thanks. I committed that on top and my framebuffer console over
> DVI is still working. I'm dubious that it's thorough enough to have
> value (sadly I have neither the time nor the motivation to fight with
> HDMI and I2S audio), but feel free to consider that a tested-by if you
> wish.
Well, "nothing obviously broken" is good enough, thanks.
I don't have (or use) I2S video on my TDA998x, and that's something
which is in Jyri's interest area.
--
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
* [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Arnd Bergmann @ 2016-11-08 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB25366BC8FF59C68E2823245EF8A60@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Tuesday, November 8, 2016 6:49:51 AM CET Y.B. Lu wrote:
> Hi Arnd,
>
>
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Tuesday, November 08, 2016 5:20 AM
> > To: Y.B. Lu
> > Cc: linuxppc-dev at lists.ozlabs.org; linux-mmc at vger.kernel.org;
> > ulf.hansson at linaro.org; Scott Wood; Mark Rutland; Greg Kroah-Hartman; X.B.
> > Xie; M.H. Lian; linux-i2c at vger.kernel.org; linux-clk at vger.kernel.org;
> > Qiang Zhao; Russell King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree at vger.kernel.org; Rob Herring; Santosh Shilimkar; linux-arm-
> > kernel at lists.infradead.org; netdev at vger.kernel.org; linux-
> > kernel at vger.kernel.org; Leo Li; iommu at lists.linux-foundation.org; Kumar
> > Gala
> > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
> >
> > On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote:
> > > >
> > > > I don't see any of the contents of this header referenced by the soc
> > > > driver any more. I think you can just drop this patch.
> > > >
> > >
> > > [Lu Yangbo-B47093] This header file was included by guts.c.
> > > The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
> > >
> > > This header file was for powerpc arch before. And this patch is to
> > > made it as common header file for both ARM and PPC.
> > > Sooner or later this is needed.
> >
> > Let's discuss it once we actually need the header then, ok?
>
> [Lu Yangbo-B47093] As I said, this header file was included by guts.c in patch 4.
Ah sorry, I misread your earlier reply, thinking you meant a potential
future patch.
> The guts driver used macro SVR_MAJ/SVR_MIN for calculation which were
> defined in this header file.
> Did you suggest we dropped this patch and just calculated them in driver?
That is probably nicer here: there is not that much value in sharing
the two one-line macro definitions, and the driver already hardcodes
the numeric per-chip IDs that make up most of the header file.
Arnd
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Anurup M @ 2016-11-08 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2030692.HPgjBCTYG6@wuerfel>
On Tuesday 08 November 2016 05:15 PM, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
>> On 07/11/2016 20:08, Arnd Bergmann wrote:
>>> On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
>>>> Hi Arnd,
>>>>
>>>> The new bus type tries to model the djtag in a similar way to I2C/USB
>>>> driver arch, where we have a host bus adapter and child devices attached
>>>> to the bus. The child devices are bus driver devices and have bus
>>>> addresses. We think of the djtag as a separate bus, so we are modelling
>>>> it as such.
>>>>
>>>> The bus driver offers a simple host interface for clients to read/write
>>>> to the djtag bus: bus accesses are hidden from the client, the host
>>>> drives the bus.
>>> Ok, in that case we should probably start out by having a bus specific
>>> DT binding, and separating the description from that of the bus master
>>> device.
>> OK
>>
>>> I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the master
>>> node, and listing the children by reg property. If the address is not
>>> easily expressed as a single integer, use a larger #address-cells value.
>> We already have something equivalent to reg in "module-id" (see patch
>> 02/11), which is the slave device bus address; here's a sample:
>> + /* For L3 cache PMU */
>> + pmul3c0 {
>> + compatible = "hisilicon,hisi-pmu-l3c-v1";
>> + scl-id = <0x02>;
>> + num-events = <0x16>;
>> + num-counters = <0x08>;
>> + module-id = <0x04>;
>> + num-banks = <0x04>;
>> + cfgen-map = <0x02 0x04 0x01 0x08>;
>> + counter-reg = <0x170>;
>> + evctrl-reg = <0x04>;
>> + event-en = <0x1000000>;
>> + evtype-reg = <0x140>;
>> + };
>>
>> FYI, "module-id" is our own internal hw nomenclature.
> Yes, that was my interpretation as well. Please use the standard
> "reg" property for this then.
Hi Arnd,
Firstly my apologies for a mistake in the bindings example in ([PATCH
02/11 ..]).
The module-id property is a list as defined in the PMU bindings patch
([PATCH v1 05/11] dt-bindings .. <https://lkml.org/lkml/2016/11/2/323>).
+ djtag0: djtag at 0 {
+ compatible = "hisilicon,hip05-cpu-djtag-v1";
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ scl-id = <0x02>;
+ num-events = <0x16>;
+ num-counters = <0x08>;
+ module-id = <0x04 0x04 0x04 0x04>;
+ num-banks = <0x04>;
+ cfgen-map = <0x02 0x04 0x01 0x08>;
+ counter-reg = <0x170>;
+ evctrl-reg = <0x04>;
+ event-en = <0x1000000>;
+ evtype-reg = <0x140>;
+ };
The L3 cache in hip05/06/07 chips consist of 4 banks (each bank has PMU
registers).
In hip05/06 all L3 cache banks are identified with same module-id.
module-id = <0x04 0x04 0x04 0x04>;
But in the case hip07 chip(djtag v2), each L3 cache bank has different
module-id
module-id = <0x01 0x02 0x03 0x04>;
So in this case Please share your opinion on how to model it.
Some more detail of L3 cache PMU.
------------------------------------------------
The hip05/06/07 chips consists of a multiple Super CPU cluster (16 CPU
cores). we call it SCCL.
The L3 cache( 4 banks) is shared by all CPU cores in a SCCL.
Each L3 cache bank has PMU registers. We always take the sum of the
counters to show in perf.
Taking individual L3 cache count is not meaningful as there is no
mapping of CPU cores to individual
L3 cache banks.
Please share your suggestion.
Thanks,
Anurup
>>> Another option that we have previously used was to actually pretend that
>>> a vendor specific bus is an i2c bus and use the i2c probing infrastructure,
>>> but that only makes sense if the software side closely resembles i2c
>>> (this was the case for Allwinner I think, but I have not looked at
>>> your driver in enough detail to know if it is true here as well).
>>>
>> OK, let me check this. By chance do you remember the specific AllWinner
>> driver/hw?
> drivers/i2c/busses/i2c-sun6i-p2wi.c
>
> Arnd
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Cédric Le Goater @ 2016-11-08 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368736.y6FyG1ESuP@wuerfel>
On 11/07/2016 02:02 PM, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 3:28:01 PM CET C?dric Le Goater wrote:
>> On 11/02/2016 02:56 PM, Joel Stanley wrote:
>>> On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Wednesday 02 November 2016, C?dric Le Goater wrote:
>>>>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>>>>> other is H8S/2168 compliant.
>>>>>
>>>>> The current ipmi/bt-bmc driver implements the IPMI version and we
>>>>> should reflect its nature in the compatible node name using
>>>>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>>>>> latter should be used for a H8S interface driver if it is implemented
>>>>> one day.
>>>>>
>>>>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>>>>
>>>> We generally try to avoid changing the compatible strings after the
>>>> fact, but it's probably ok in this case.
>>
>> As the device tree changes are not merged yet, we thought we had some
>> more time to fine tune the naming.
>
> Ok, I see. No problem then.
>
>>>> I don't understand who decides which of the two interfaces is used:
>>>> is it the same register set that can be driven by either one or the
>>>> other driver, or do you expect to have two drivers that can both
>>>> be active in the same system and talk to different hardware once
>>>> you get there?
>>>
>>> It's the second case. The H8S BT has a different register layout so it
>>> would require a different driver.
>>
>> yes.
>>
>>> We don't yet have a driver for the other BT device, but there was
>>> recent talk of using it as an alternate (non-ipmi channel) between the
>>> BMC and the host. Before that discussion I wasn't aware that the H8S
>>> BT existed. I suggested we fix this up before it hits a final release.
>>>
>>> C?dric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
>>> better job of describing the hardware here?
>>
>> The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI).
>> I think we can keep the same naming.
>
> Ok
>
>>> While we're modifying the binding, should we add a compat string for
>>> the ast2500?
>>
>> Well, if the change in this patch is fine for all, may be we can add
>> the ast2500 compat string in a followup patch ?
>
> Sounds good to me.
OK. So, how do we proceed with this patch ? Who would include it in its
tree ?
Thanks,
C.
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-08 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108145534.GE1575@localhost.localdomain>
On 11/08/2016 03:55 PM, Charles Keepax wrote:
>>> diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
>>> > > index 89c5a62..8c88680 100644
>>> > > --- a/arch/arm/mach-s3c64xx/pl080.c
>>> > > +++ b/arch/arm/mach-s3c64xx/pl080.c
>> > <snip>
>>> > > @@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
>>> > > .put_xfer_signal = pl08x_put_xfer_signal,
>>> > > .slave_channels = s3c64xx_dma0_info,
>>> > > .num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
>>> > > + .slave_map = s3c64xx_dma0_slave_map,
>>> > > + .slavecnt = ARRAY_SIZE(s3c64xx_dma0_slave_map),
>>> > > };
>> >
>> > Here we add a .slavecnt but the pl08x_platform_data structure doesn't
>> > contain that field. I can't see it on the branch you linked in
>> > the cover letter either, is it added by a patch on another branch
>> > I am missing?
>> >
> Ah I think I see it should be .slave_map_len here.
Yeah, sorry, I fixed it after getting report from the kbuild test
but have forgotten to push changes to the git tree.
I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
issue fixed and added initialization of the filer function.
-------------------8<-------------------------
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..d441c4b 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2307,6 +2307,10 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_id;
}
-------------------8<-------------------------
--
Thanks,
Sylwester
^ permalink raw reply related
* [GIT PULL] NXP LPC32xx ARM SoC cleanup for v4.10
From: Sylvain Lemieux @ 2016-11-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx cleanup for v4.10.
Thank you in advance.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/sylemieux/linux-lpc32xx.git tags/lpc32xx-cleanup-v4.10
for you to fetch changes up to d1193df9c3cbce699d07c352bb3c055cd827db4d:
ARM: lpc32xx: remove unused header file clock.h (2016-10-25 13:33:01 -0400)
----------------------------------------------------------------
NXP LPC32xx ARM SoC cleanup for v4.10
This includes a few cleanup changes:
* remove unused header file mach/irqs.h;
* remove unused header file clock.h.
----------------------------------------------------------------
Vladimir Zapolskiy (2):
ARM: lpc32xx: remove unused header file mach/irqs.h
ARM: lpc32xx: remove unused header file clock.h
arch/arm/mach-lpc32xx/clock.h | 38 ----------
arch/arm/mach-lpc32xx/common.h | 1 -
arch/arm/mach-lpc32xx/include/mach/irqs.h | 117 ------------------------------
arch/arm/mach-lpc32xx/pm.c | 1 -
4 files changed, 157 deletions(-)
delete mode 100644 arch/arm/mach-lpc32xx/clock.h
delete mode 100644 arch/arm/mach-lpc32xx/include/mach/irqs.h
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108024559.GA20591@arm.com>
On 11/07/2016 09:45 PM, Will Deacon wrote:
> Hi all,
>
> I figured this was a reasonable post to piggy-back on for the LPC minutes
> relating to guest MSIs on arm64.
>
> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
>> We can always have QEMU reject hot-adding the device if the reserved
>> region overlaps existing guest RAM, but I don't even really see how we
>> advise users to give them a reasonable chance of avoiding that
>> possibility. Apparently there are also ARM platforms where MSI pages
>> cannot be remapped to support the previous programmable user/VM
>> address, is it even worthwhile to support those platforms? Does that
>> decision influence whether user programmable MSI reserved regions are
>> really a second class citizen to fixed reserved regions? I expect
>> we'll be talking about this tomorrow morning, but I certainly haven't
>> come up with any viable solutions to this. Thanks,
>
> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> microconference. I presented some slides to illustrate some of the issues
> we're trying to solve:
>
> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>
> Punit took some notes (thanks!) on the etherpad here:
>
> https://etherpad.openstack.org/p/LPC2016_PCI
>
> although the discussion was pretty lively and jumped about, so I've had
> to go from memory where the notes didn't capture everything that was
> said.
>
> To summarise, arm64 platforms differ in their handling of MSIs when compared
> to x86:
>
> 1. The physical memory map is not standardised (Jon pointed out that
> this is something that was realised late on)
> 2. MSIs are usually treated the same as DMA writes, in that they must be
> mapped by the SMMU page tables so that they target a physical MSI
> doorbell
> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> doorbell built into the PCI RC)
Chaulk this case to 'the learning curve'.
Q35 chipset (the one being use for x86-PCIe qemu model) had no intr-remap hw,
only DMA addrs destined for real memory. assigned-device intrs had to be caught
by kvm & injected into guests, and yes, a DoS was possible... and thus,
the intr-remap support being done after initial iommu support.
> 4. Platforms typically have some set of addresses that abort before
> reaching the SMMU (e.g. because the PCI identifies them as P2P).
ARM platforms that don't implement the equivalent of ACS (in PCI bridges within
a PCIe switch) are either not device-assignment capable, or the IOMMU domain
expands across the entire peer-to-peer (sub-)tree.
ACS(-like) functionality is a fundamental component to the security model,
as is the IOMMU itself. Without it, it's equivalent to not having an IOMMU.
Dare I ask?: Can these systems, or parts of these systems, just be deemed
"incomplete" or "not 100% secure" wrt device assignment, and other systems
can or will be ???
Not much different then the first x86 systems that tried to get it right
the first few times... :-/
I'm hearing (parts of) systems that are just not properly designed
for device-assignment use-case, probably b/c this (system) architecture
hasn't been pulled together from the variouis component architectures
(CPU, SMMU, IOT, etc.).
>
> All of this means that userspace (QEMU) needs to identify the memory
> regions corresponding to points (3) and (4) and ensure that they are
> not allocated in the guest physical (IPA) space. For platforms that can
> remap the MSI doorbell as in (2), then some space also needs to be
> allocated for that.
>
Again, proper ACS features/control eliminates this need.
A (multi-function) device should never be able to perform
IO to itself via its PCIe interface. Bridge-ACS pushes everything
up to SMMU for desitination resolution.
Without ACS, I don't see how a guest is migratible from one system to
another, unless the system-migration-group consists of system that
are exactly the same (wrt IO) [less/more system memory &/or cpu does
not affect VM system map.
Again, the initial Linux implementation did not have ACS,
but was 'resolved' by the default/common system mapping putting the PCI devices
into an area that was blocked from memory use (generally 3G->4G space).
ARM may not have that single, simple implementation, but a method to
indicated reserved regions, and then a check for matching/non-matching reserved
regions for guest migration, is the only way I see to resolve this issue
until ACS is sufficiently supported int the hw subsystems to be used
for device-assignment.
> Rather than treat these as separate problems, a better interface is to
> tell userspace about a set of reserved regions, and have this include
> the MSI doorbell, irrespective of whether or not it can be remapped.
> Don suggested that we statically pick an address for the doorbell in a
> similar way to x86, and have the kernel map it there. We could even pick
> 0xfee00000.
I suggest picking a 'relative-fixed' address: the last n-pages of system memory
address space, i.e.,
0xfff[....]fee00000. ... sign-extended 0xfee00000.
That way, no matter how large memory is, there is no hole, it's just the
last 2M of memory ... every system has an end of memory. :-p
> If it conflicts with a reserved region on the platform (due
>to (4)), then we'd obviously have to (deterministically?) allocate it
> somewhere else, but probably within the bottom 4G.
>
why? It's more likely for a hw platform to use this <4G address range
for device mmio, then the upper-most address space for device space. Even if
platforms use upper-most address space now, it's not rocket science to subtract
upper 2M from existing use, then allocate device space from there (downward).
... and if you pull a 'there are systems that have hard-wired addresses
in upper-most 2M', then we can look@if we can quirk these systems, or
just not support them for this use-case.
> The next question is how to tell userspace about all of the reserved
> regions. Initially, the idea was to extend VFIO, however Alex pointed
Won't need to, if upper memory space is passed; take upper 2M and done. ;-)
For now, you'll need a whole new qemu paradigm, for a (hopefully) short-term
problem. I suggest coming up with a short-term, default 'safe' place for
devices & memory to avoid the qemu disruption.
> out a horrible scenario:
>
> 1. QEMU spawns a VM on system 0
> 2. VM is migrated to system 1
> 3. QEMU attempts to passthrough a device using PCI hotplug
>
> In this scenario, the guest memory map is chosen at step (1), yet there
> is no VFIO fd available to determine the reserved regions. Furthermore,
> the reserved regions may vary between system 0 and system 1. This pretty
> much rules out using VFIO to determine the reserved regions. Alex suggested
> that the SMMU driver can advertise the regions via /sys/class/iommu/. This
> would solve part of the problem, but migration between systems with
> different memory maps can still cause problems if the reserved regions
> of the new system conflict with the guest memory map chosen by QEMU.
> Jon pointed out that most people are pretty conservative about hardware
> choices when migrating between them -- that is, they may only migrate
> between different revisions of the same SoC, or they know ahead of time
> all of the memory maps they want to support and this could be communicated
> by way of configuration to libvirt. It would be up to QEMU to fail the
> hotplug if it detected a conflict. Alex asked if there was a security
> issue with DMA bypassing the SMMU, but there aren't currently any systems
> where that is known to happen. Such a system would surely not be safe for
> passthrough.
>
> Ben mused that a way to handle conflicts dynamically might be to hotplug
> on the entire host bridge in the guest, passing firmware tables describing
> the new reserved regions as a property of the host bridge. Whilst this
> may well solve the issue, it was largely considered future work due to
> its invasive nature and dependency on firmware tables (and guest support)
> that do not currently exist.
>
> Will
>
^ permalink raw reply
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108153949.GF1575@localhost.localdomain>
On 11/08/2016 04:39 PM, Charles Keepax wrote:
> Hmm... fixing the bug I mentioned in my other email this still
> seems to cause some problems with my SPI on Cragganmore:
>
> [ 200.210213] wm0010 spi0.0: I/O Error: rx-1 tx-1 res:rx-f tx-f len-2632
> [ 200.211275] wm0010 spi0.0: SPI transfer failed: -5
>
> I am still looking into it, without your patches work the wm0010
> comes up. A few other small things seem to have been broken in
> mainline since last time I fired up this board as well which is
> slowing me down a little (network seems to have stopped coming
> up and one of the regulators on the SD card is spamming me with
> warnings).
Thanks for giving it a try. Is it any better with a change as below?
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index d5c75c8..d441c4b 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2310,6 +2310,7 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
} else {
pl08x->slave.filter.map = pl08x->pd->slave_map;
pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_id;
}
^ permalink raw reply related
* [GIT PULL] NXP LPC32xx ARM SoC DT updates for v4.10
From: Sylvain Lemieux @ 2016-11-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
please consider to include NXP LPC32xx device tree updates for v4.10.
Thank you in advance.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/sylemieux/linux-lpc32xx.git tags/lpc32xx-dt-v4.10
for you to fetch changes up to 1754906fffcabdd166f6aec85eb9a3a28de531b8:
ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2 (2016-10-25 13:29:31 -0400)
----------------------------------------------------------------
NXP LPC32xx ARM SoC device tree updates for v4.10
This includes a single functional change:
* set default parent clock for PWM1 & PWM2.
----------------------------------------------------------------
Sylvain Lemieux (1):
ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2
arch/arm/boot/dts/lpc32xx.dtsi | 4 ++++
1 file changed, 4 insertions(+)
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108154038.GS1041@n2100.armlinux.org.uk>
On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> this point.
Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.0(release):14b6608
NOTICE: BL1: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.0(release):14b6608
NOTICE: BL2: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL3-1
NOTICE: BL3-1: v1.0(release):14b6608
NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.
and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:
[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:
and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.) "devices" shows nothing that's even remotely English.
So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.
--
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 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-08 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108154038.GS1041@n2100.armlinux.org.uk>
On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware. I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>
No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.
>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>
No, we have seen issues in past especially UEFI.
>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images. I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>
[...]
> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob 0xE0000000 - 0xE00EFFFF
> FV Hob 0xFE07B000 - 0xFE8253BF
> FV2 Hob 0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>
Ah that's good, some progress.
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> this point.
>
I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.
Cmd> flash
Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
I will looking into that further.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-08 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108120323.GC15297@leverpostej>
On Tuesday, November 8, 2016 12:03:23 PM CET 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.
Actually PowerPC has a vaguely similar mechanism.
> > 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).
I think it is rather unlikely that we have to deal with multiple
instances in the future, it's more likely that future platforms
won't have any I/O ports at all, which is why I was advocating for
simplicity here.
> > +type in##bw(unsigned long addr) \
> > +{ \
> > + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> > + arm64_extio_ops->end < addr) \
> > + return read##bw(PCI_IOBASE + addr); \
> > + return arm64_extio_ops->pfin ? \
> > + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
> > + addr, sizeof(type)) : -1; \
> > +} \
> > + \
> > +void out##bw(type value, unsigned long addr) \
> > +{ \
> > + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> > + arm64_extio_ops->end < addr) \
> > + write##bw(value, PCI_IOBASE + addr); \
> > + else \
> > + if (arm64_extio_ops->pfout) \
> > + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > + addr, value, sizeof(type)); \
> > +} \
> > + \
> > +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
> > +{ \
> > + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> > + arm64_extio_ops->end < addr) \
> > + reads##bw(PCI_IOBASE + addr, buffer, count); \
> > + else \
> > + if (arm64_extio_ops->pfins) \
> > + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> > + addr, buffer, sizeof(type), count); \
> > +} \
> > + \
> > +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
> > +{ \
> > + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> > + arm64_extio_ops->end < addr) \
> > + writes##bw(PCI_IOBASE + addr, buffer, count); \
> > + else \
> > + if (arm64_extio_ops->pfouts) \
> > + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> > + addr, buffer, sizeof(type), count); \
> > +}
> > +
>
> So all PCI I/O will be slowed down by irrelevant checks when this is
> enabled?
I don't see a better alternative. I earlier suggested having these
out of line so we don't grow the object code too much when it is
enabled.
Performance of PIO accessors is not an issue here though, any bus
access will by definition be orders of magnitude slower than the
added branches and dereferences here.
> [...]
>
> > +static inline void arm64_set_extops(struct extio_ops *ops)
> > +{
> > + if (ops)
> > + WRITE_ONCE(arm64_extio_ops, ops);
> > +}
>
> Why WRITE_ONCE()?
>
> Is this not protected/propagated by some synchronisation mechanism?
>
> WRITE_ONCE() is not sufficient to ensure that this is consistently
> observed by readers, and regardless, I don't see READ_ONCE() anywhere in
> this patch.
>
> This looks very suspicious.
Agreed, this looks wrong.
Arnd
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Will Deacon @ 2016-11-08 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478576829-112707-2-git-send-email-yuanzhichang@hisilicon.com>
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.
>
> 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.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> arch/arm64/Kconfig | 6 +++
> arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
> arch/arm64/include/asm/io.h | 29 +++++++++++++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/extio.c | 27 ++++++++++++
> 5 files changed, 157 insertions(+)
> create mode 100644 arch/arm64/include/asm/extio.h
> create mode 100644 arch/arm64/kernel/extio.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..b44070b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
> config ARCH_MMAP_RND_COMPAT_BITS_MAX
> default 16
>
> +config ARM64_INDIRECT_PIO
> + bool "access peripherals with legacy I/O port"
> + help
> + Support special accessors for ISA I/O devices. This is needed for
> + SoCs that do not support standard read/write for the ISA range.
> +
> config NO_IOPORT_MAP
> def_bool y if !PCI
>
> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
> new file mode 100644
> index 0000000..6ae0787
> --- /dev/null
> +++ b/arch/arm64/include/asm/extio.h
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __LINUX_EXTIO_H
> +#define __LINUX_EXTIO_H
> +
> +struct extio_ops {
> + unsigned long start;/* inclusive, sys io addr */
> + unsigned long end;/* inclusive, sys io addr */
> +
> + u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
> + size_t dlen);
> + u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
> + size_t dlen, unsigned int count);
> + void (*pfouts)(void *devobj, unsigned long ptaddr,
> + const void *outbuf, size_t dlen,
> + unsigned int count);
> + void *devpara;
> +};
> +
> +extern struct extio_ops *arm64_extio_ops;
> +
> +#define DECLARE_EXTIO(bw, type) \
> +extern type in##bw(unsigned long addr); \
> +extern void out##bw(type value, unsigned long addr); \
> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
> +
> +#define BUILD_EXTIO(bw, type) \
> +type in##bw(unsigned long addr) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + return read##bw(PCI_IOBASE + addr); \
> + return arm64_extio_ops->pfin ? \
> + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
> + addr, sizeof(type)) : -1; \
> +} \
> + \
> +void out##bw(type value, unsigned long addr) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + write##bw(value, PCI_IOBASE + addr); \
> + else \
> + if (arm64_extio_ops->pfout) \
> + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> + addr, value, sizeof(type)); \
> +} \
> + \
> +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + reads##bw(PCI_IOBASE + addr, buffer, count); \
> + else \
> + if (arm64_extio_ops->pfins) \
> + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
> + addr, buffer, sizeof(type), count); \
> +} \
> + \
> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
> +{ \
> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
> + arm64_extio_ops->end < addr) \
> + writes##bw(PCI_IOBASE + addr, buffer, count); \
> + else \
> + if (arm64_extio_ops->pfouts) \
> + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
> + addr, buffer, sizeof(type), count); \
> +}
> +
> +static inline void arm64_set_extops(struct extio_ops *ops)
> +{
> + if (ops)
> + WRITE_ONCE(arm64_extio_ops, ops);
Why does this need to be WRITE_ONCE? You don't have READ_ONCE on the reader
side. Also, what if multiple drivers want to set different ops for distinct
address ranges?
> +}
> +
> +#endif /* __LINUX_EXTIO_H*/
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0bba427..136735d 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -31,6 +31,7 @@
> #include <asm/early_ioremap.h>
> #include <asm/alternative.h>
> #include <asm/cpufeature.h>
> +#include <asm/extio.h>
>
> #include <xen/xen.h>
>
> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>
> +
> +/*
> + * redefine the in(s)b/out(s)b for indirect-IO.
> + */
> +#ifdef CONFIG_ARM64_INDIRECT_PIO
> +#define inb inb
> +#define outb outb
> +#define insb insb
> +#define outsb outsb
> +/* external declaration */
> +DECLARE_EXTIO(b, u8)
> +
> +#define inw inw
> +#define outw outw
> +#define insw insw
> +#define outsw outsw
> +
> +DECLARE_EXTIO(w, u16)
> +
> +#define inl inl
> +#define outl outl
> +#define insl insl
> +#define outsl outsl
> +
> +DECLARE_EXTIO(l, u32)
> +#endif
> +
> +
> /*
> * String version of I/O memory access operations.
> */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 7d66bba..60e0482 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
> sys_compat.o entry32.o
> arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
> arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
> arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
> arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
> arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> new file mode 100644
> index 0000000..647b3fa
> --- /dev/null
> +++ b/arch/arm64/kernel/extio.c
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/io.h>
> +
> +struct extio_ops *arm64_extio_ops;
> +
> +
> +BUILD_EXTIO(b, u8)
> +
> +BUILD_EXTIO(w, u16)
> +
> +BUILD_EXTIO(l, u32)
Is there no way to make this slightly more generic, so that it can be
re-used elsewhere? For example, if struct extio_ops was common, then
you could have the singleton (which maybe should be an interval tree?),
type definition, setter function and the BUILD_EXTIO invocations
somewhere generic, rather than squirelled away in the arch backend.
Will
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e83e8462-6d63-7253-f69c-afb507463bba@arm.com>
On Tue, Nov 08, 2016 at 04:08:38PM +0000, Sudeep Holla wrote:
> I will focus on this and see what's happening. I have issue with network
> on my setup with debug build and Linaro guys are not seeing it. I revert
> to release build of UEFI for that. Anyways one suggestion I have right
> now is to erase the second partition of NOR flash where the old UEFI
> config is placed and it could be conflicting with the new UEFI image.
>
> Cmd> flash
>
>
> Switching on main power...
> PMIC RAM configuration (pms_v105.bin)...
> IOFPGA config: PASSED
> Enabling usb remote...
>
>
> Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
>
> I will looking into that further.
Still behaves the same, stopping at:
FV2 Hob 0xFE07B000 - 0xFE8253BF
--
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 V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-08 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13493313.OkuDZEY5WO@wuerfel>
On Tuesday, November 8, 2016 5:09:59 PM CET Arnd Bergmann wrote:
>
> I don't see a better alternative. I earlier suggested having these
> out of line so we don't grow the object code too much when it is
> enabled.
>
On second look, I see that they are all done out of line, I would
just move around the BUILD_EXTIO macro to the file that uses it
and remove and open-code the DECLARE_EXTIO() as that makes it easier
to grep.
Arnd
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-08 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMSwwyoi8Vb_-+6dViB8PaBRUoCZYBcrzDjgX9EJnv_mvQ@mail.gmail.com>
On 11/08/2016 09:52 AM, Rados?aw Pietrzyk wrote:
> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>> Hi Rados?aw
>>
>> Many thanks for reviewing.
>>
>> On 11/07/2016 03:57 PM, Rados?aw Pietrzyk wrote:
>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>> + const char *parent_name, unsigned long flags,
>>>> + void __iomem *reg, u8 shift, u8 width,
>>>> + u8 clk_divider_flags, const struct clk_div_table *table,
>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>> +{
>>>> + struct stm32f4_pll_div *pll_div;
>>>> + struct clk_hw *hw;
>>>> + struct clk_init_data init;
>>>> + int ret;
>>>> +
>>>> + /* allocate the divider */
>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>> + if (!pll_div)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + init.name = name;
>>>> + init.ops = &stm32f4_pll_div_ops;
>>>> + init.flags = flags;
>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>> divider ops.
>> I don't want to offer the possibility to change the vco clock through the
>> divisor of the pll (only by a boot-loader or by DT).
>>
>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the SAI
>> frequencies.
>>
>> I used same structure for internal divisors of the pll (p, q, r) and for
>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>
>> These divisors are similar because we have to switch off the pll before
>> changing the rate.
>>
> But changing pll and lcd dividers only may not be enough for getting
> very specific pixelclocks and that might require changing the VCO
> frequency itself. The rest of the SAI tree should be recalculated
> then.
I agree but it seems to be too much complicated to recalculate all PLL
divisors if we change the vco clock.
You mean to use Clock notifier callback ?
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Arnd Bergmann @ 2016-11-08 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108114953.GB15297@leverpostej>
On Tuesday, November 8, 2016 11:49:53 AM CET Mark Rutland wrote:
> On Tue, Nov 08, 2016 at 11:47:08AM +0800, zhichang.yuan wrote:
> > +Hisilicon Hip06 low-pin-count device
> > + Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> > + locate on LPC bus can be accessed direclty. But some SoCs have independent
> > + LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> > + Hisilicon Hip06 implements this LPC device.
>
> s/direclty/directly/
>
> My understanding of ISA (which may be flawed) is that it's not part of
> the PCI host bridge, but rather on x86 it happens to share the IO space
> with PCI.
On normal systems, ISA or LPC are behind a PCI bridge device, which
passes down both low addresses of I/O space and memory space.
> So, how about this becomes:
>
> Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
> provides access to some legacy ISA devices.
>
> I believe that we could theoretically have multiple independent LPC/ISA
> busses, as is possible with PCI on !x86 systems. If the current ISA code
> assumes a singleton bus, I think that's something that needs to be fixed
> up more generically.
>
> I don't see why we should need any architecture-specific code here. Why
> can we not fix up the ISA bus code in drivers/of/address.c such that it
> handles multiple ISA bus instances, and translates all sub-device
> addresses relative to the specific bus instance?
I think it is a relatively safe assumption that there is only one
ISA bridge. A lot of old drivers hardcode PIO or memory addresses
when talking to an ISA device, so having multiple instances is
already problematic.
What is odd about ARM64 here is that the PIO space is not shared among
all ISA and PCI buses in some cases.
Arnd
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-08 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478576829-112707-4-git-send-email-yuanzhichang@hisilicon.com>
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.
Arnd
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-11-08 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e0ed43b-9a3e-48d4-4e8a-60d6f25ca4ee@suse.com>
On Tue, Nov 08, 2016 at 10:59:43AM +0100, Matthias Brugger wrote:
> > /* don't globally reset PL if we're doing partial reconfig */
> > if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> >+ if (!zynq_fpga_has_sync(buf, count)) {
>
> Maybe we should add an error message here to let the user know what went
> wrong, as I think this error path could easily be hit by an user.
Sure, happy with this wording:
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index de475a6a1882..2f3da4c6e2e6 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -181,7 +181,7 @@ static irqreturn_t zynq_fpga_isr(int irq, void *data)
*/
static bool zynq_fpga_has_sync(const char *buf, size_t count)
{
- for (; count > 4; buf += 4, --count)
+ for (; count > 4; buf += 4, count -= 4)
if (buf[0] == 0x66 && buf[1] == 0x55 && buf[2] == 0x99 &&
buf[3] == 0xaa)
return true;
@@ -200,8 +200,11 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
/* The hardware can only DMA multiples of 4 bytes, and we need at
* least the sync word and something else to do anything.
*/
- if (count <= 4 || (count % 4) != 0)
+ if (count <= 4 || (count % 4) != 0) {
+ dev_err(priv->dev,
+ "Invalid bitstream size, must be multiples of 4 bytes");
return -EINVAL;
+ }
err = clk_enable(priv->clk);
if (err)
@@ -210,6 +213,8 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
/* don't globally reset PL if we're doing partial reconfig */
if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
if (!zynq_fpga_has_sync(buf, count)) {
+ dev_err(priv->dev,
+ "Invalid bitstream, could not find a sync word. Bitstream must be a byte swaped .bin file");
err = -EINVAL;
goto out_err;
}
^ permalink raw reply related
* [PATCH 4/6] clk: stm32f4: Add I2S clock
From: Gabriel Fernandez @ 2016-11-08 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <08ad0f8c-bcdf-4835-9f07-167e129604bd@linaro.org>
On 11/07/2016 03:14 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch introduces I2S clock for stm32f4 soc.
>> The I2S clock could be derived from an external clock or from pll-i2s
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index 5fa5d51..b7cb359 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -216,6 +216,7 @@ enum {
>> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
>> PLL_VCO_I2S, PLL_VCO_SAI,
>> CLK_LCD,
>> + CLK_I2S,
>
> Sorry, this has just clicked and it applies to most of the other
> patches, but adding things to this list effectively extends the clock
> bindings (i.e. the list of valid "other" clocks access with a primary
> index of 1).
>
> This list if a list of "arbitrary" constants by which DT periphericals
> can be linked to specific clocks.
>
> So...
>
> 1) If a clock is introduced here we should update the clock binding
> documentations.
>
> 2) If no peripheral can connect to the clock (because it is internal
> to the clock gen logic and peripherals must connect to the gated
> version) it should not be included in this enum.
>
> 3) I failed to mention this when the four undocumented clocks
> (LSI, LSE, HSE_RTC and RTC) were added.
>
> 4) I *should* have added a comment explaining the above to the code.
>
>
ok i agree
>> END_PRIMARY_CLK
>> };
>>
>> @@ -967,6 +968,8 @@ static struct clk_hw *stm32_register_cclk(struct
>> device *dev, const char *name,
>>
>> static const char *sdmux_parents[2] = { "pll48", "sys" };
>>
>> +static const char *i2s_parents[2] = { "plli2s-r", NULL };
>> +
>> struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> @@ -1005,7 +1008,7 @@ struct stm32f4_clk_data {
>>
>> static void __init stm32f4_rcc_init(struct device_node *np)
>> {
>> - const char *hse_clk;
>> + const char *hse_clk, *i2s_in_clk;
>> int n;
>> const struct of_device_id *match;
>> const struct stm32f4_clk_data *data;
>> @@ -1038,6 +1041,7 @@ static void __init stm32f4_rcc_init(struct
>> device_node *np)
>> stm32f4_gate_map = data->gates_map;
>>
>> hse_clk = of_clk_get_parent_name(np, 0);
>> + i2s_in_clk = of_clk_get_parent_name(np, 1);
>
> Again this looks like a change to the DT bindings.
>
ok
> Also does the code work if i2s_in_clk is NULL or as you hoping to get
> away with a not-backwards compatible change?
>
>
yes it works if i2s_in_clk is NULL.
BR
Gabriel
> Daniel.
>
>
>>
>> clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
>> 16000000, 160000);
>> @@ -1053,6 +1057,12 @@ static void __init stm32f4_rcc_init(struct
>> device_node *np)
>> clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll(pllsrc,
>> &data->pll_data[2], &stm32f4_clk_lock);
>>
>> + i2s_parents[1] = i2s_in_clk;
>> +
>> + clks[CLK_I2S] = clk_hw_register_mux_table(NULL, "i2s",
>> + i2s_parents, ARRAY_SIZE(i2s_parents), 0,
>> + base + STM32F4_RCC_CFGR, 23, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> sys_parents[1] = hse_clk;
>> clk_register_mux_table(
>> NULL, "sys", sys_parents, ARRAY_SIZE(sys_parents), 0,
>>
>
^ permalink raw reply
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-08 16:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support to PM8821 PMIC and interrupt support.
PM8821 is companion device that supplements primary PMIC PM8921 IC.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Tested this patch for MPP and IRQ functionality on IFC6410 and SD600 EVAL
board with mpps PM8821 and PM8921.
.../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
drivers/mfd/pm8921-core.c | 368 +++++++++++++++++++--
2 files changed, 340 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
index 37a088f..8f1b4ec 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
@@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
Definition: must be one of:
"qcom,pm8058"
"qcom,pm8921"
+ "qcom,pm8821"
- #address-cells:
Usage: required
diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index 0e3a2ea..28c2470 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -28,16 +28,26 @@
#include <linux/mfd/core.h>
#define SSBI_REG_ADDR_IRQ_BASE 0x1BB
-
-#define SSBI_REG_ADDR_IRQ_ROOT (SSBI_REG_ADDR_IRQ_BASE + 0)
-#define SSBI_REG_ADDR_IRQ_M_STATUS1 (SSBI_REG_ADDR_IRQ_BASE + 1)
-#define SSBI_REG_ADDR_IRQ_M_STATUS2 (SSBI_REG_ADDR_IRQ_BASE + 2)
-#define SSBI_REG_ADDR_IRQ_M_STATUS3 (SSBI_REG_ADDR_IRQ_BASE + 3)
-#define SSBI_REG_ADDR_IRQ_M_STATUS4 (SSBI_REG_ADDR_IRQ_BASE + 4)
-#define SSBI_REG_ADDR_IRQ_BLK_SEL (SSBI_REG_ADDR_IRQ_BASE + 5)
-#define SSBI_REG_ADDR_IRQ_IT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 6)
-#define SSBI_REG_ADDR_IRQ_CONFIG (SSBI_REG_ADDR_IRQ_BASE + 7)
-#define SSBI_REG_ADDR_IRQ_RT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 8)
+#define SSBI_PM8821_REG_ADDR_IRQ_BASE 0x100
+
+#define SSBI_REG_ADDR_IRQ_ROOT (0)
+#define SSBI_REG_ADDR_IRQ_M_STATUS1 (1)
+#define SSBI_REG_ADDR_IRQ_M_STATUS2 (2)
+#define SSBI_REG_ADDR_IRQ_M_STATUS3 (3)
+#define SSBI_REG_ADDR_IRQ_M_STATUS4 (4)
+#define SSBI_REG_ADDR_IRQ_BLK_SEL (5)
+#define SSBI_REG_ADDR_IRQ_IT_STATUS (6)
+#define SSBI_REG_ADDR_IRQ_CONFIG (7)
+#define SSBI_REG_ADDR_IRQ_RT_STATUS (8)
+
+#define PM8821_TOTAL_IRQ_MASTERS 2
+#define PM8821_BLOCKS_PER_MASTER 7
+#define PM8821_IRQ_MASTER1_SET 0x01
+#define PM8821_IRQ_CLEAR_OFFSET 0x01
+#define PM8821_IRQ_RT_STATUS_OFFSET 0x0f
+#define PM8821_IRQ_MASK_REG_OFFSET 0x08
+#define SSBI_REG_ADDR_IRQ_MASTER0 0x30
+#define SSBI_REG_ADDR_IRQ_MASTER1 0xb0
#define PM_IRQF_LVL_SEL 0x01 /* level select */
#define PM_IRQF_MASK_FE 0x02 /* mask falling edge */
@@ -54,30 +64,41 @@
#define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
#define PM8921_NR_IRQS 256
+#define PM8821_NR_IRQS 112
struct pm_irq_chip {
struct regmap *regmap;
spinlock_t pm_irq_lock;
struct irq_domain *irqdomain;
+ unsigned int irq_reg_base;
unsigned int num_irqs;
unsigned int num_blocks;
unsigned int num_masters;
u8 config[0];
};
+struct pm8xxx_data {
+ int num_irqs;
+ unsigned int irq_reg_base;
+ const struct irq_domain_ops *irq_domain_ops;
+ void (*irq_handler)(struct irq_desc *desc);
+};
+
static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
unsigned int *ip)
{
int rc;
spin_lock(&chip->pm_irq_lock);
- rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
+ rc = regmap_write(chip->regmap,
+ chip->irq_reg_base + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
if (rc) {
pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
goto bail;
}
- rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
+ rc = regmap_read(chip->regmap,
+ chip->irq_reg_base + SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
if (rc)
pr_err("Failed Reading Status rc=%d\n", rc);
bail:
@@ -91,14 +112,16 @@ pm8xxx_config_irq(struct pm_irq_chip *chip, unsigned int bp, unsigned int cp)
int rc;
spin_lock(&chip->pm_irq_lock);
- rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
+ rc = regmap_write(chip->regmap,
+ chip->irq_reg_base + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
if (rc) {
pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
goto bail;
}
cp |= PM_IRQF_WRITE;
- rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_CONFIG, cp);
+ rc = regmap_write(chip->regmap,
+ chip->irq_reg_base + SSBI_REG_ADDR_IRQ_CONFIG, cp);
if (rc)
pr_err("Failed Configuring IRQ rc=%d\n", rc);
bail:
@@ -137,8 +160,8 @@ static int pm8xxx_irq_master_handler(struct pm_irq_chip *chip, int master)
unsigned int blockbits;
int block_number, i, ret = 0;
- ret = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_M_STATUS1 + master,
- &blockbits);
+ ret = regmap_read(chip->regmap, chip->irq_reg_base +
+ SSBI_REG_ADDR_IRQ_M_STATUS1 + master, &blockbits);
if (ret) {
pr_err("Failed to read master %d ret=%d\n", master, ret);
return ret;
@@ -165,7 +188,8 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
chained_irq_enter(irq_chip, desc);
- ret = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_ROOT, &root);
+ ret = regmap_read(chip->regmap,
+ chip->irq_reg_base + SSBI_REG_ADDR_IRQ_ROOT, &root);
if (ret) {
pr_err("Can't read root status ret=%d\n", ret);
return;
@@ -182,6 +206,122 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
chained_irq_exit(irq_chip, desc);
}
+static int pm8821_read_master_irq(const struct pm_irq_chip *chip,
+ int m, unsigned int *master)
+{
+ unsigned int base;
+
+ if (!m)
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
+ else
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
+
+ return regmap_read(chip->regmap, base, master);
+}
+
+static int pm8821_read_block_irq(struct pm_irq_chip *chip, int master,
+ u8 block, unsigned int *bits)
+{
+ int rc;
+
+ unsigned int base;
+
+ if (!master)
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
+ else
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
+
+ spin_lock(&chip->pm_irq_lock);
+
+ rc = regmap_read(chip->regmap, base + block, bits);
+ if (rc)
+ pr_err("Failed Reading Status rc=%d\n", rc);
+
+ spin_unlock(&chip->pm_irq_lock);
+ return rc;
+}
+
+static int pm8821_irq_block_handler(struct pm_irq_chip *chip,
+ int master_number, int block)
+{
+ int pmirq, irq, i, ret;
+ unsigned int bits;
+
+ ret = pm8821_read_block_irq(chip, master_number, block, &bits);
+ if (ret) {
+ pr_err("Failed reading %d block ret=%d", block, ret);
+ return ret;
+ }
+ if (!bits) {
+ pr_err("block bit set in master but no irqs: %d", block);
+ return 0;
+ }
+
+ /* Convert block offset to global block number */
+ block += (master_number * PM8821_BLOCKS_PER_MASTER) - 1;
+
+ /* Check IRQ bits */
+ for (i = 0; i < 8; i++) {
+ if (bits & BIT(i)) {
+ pmirq = block * 8 + i;
+ irq = irq_find_mapping(chip->irqdomain, pmirq);
+ generic_handle_irq(irq);
+ }
+ }
+
+ return 0;
+}
+
+static int pm8821_irq_read_master(struct pm_irq_chip *chip,
+ int master_number, u8 master_val)
+{
+ int ret = 0;
+ int block;
+
+ for (block = 1; block < 8; block++) {
+ if (master_val & BIT(block)) {
+ ret |= pm8821_irq_block_handler(chip,
+ master_number, block);
+ }
+ }
+
+ return ret;
+}
+
+static void pm8821_irq_handler(struct irq_desc *desc)
+{
+ struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
+ struct irq_chip *irq_chip = irq_desc_get_chip(desc);
+ int ret;
+ unsigned int master;
+
+ chained_irq_enter(irq_chip, desc);
+ /* check master 0 */
+ ret = pm8821_read_master_irq(chip, 0, &master);
+ if (ret) {
+ pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
+ return;
+ }
+
+ if (master & ~PM8821_IRQ_MASTER1_SET)
+ pm8821_irq_read_master(chip, 0, master);
+
+ /* check master 1 */
+ if (!(master & PM8821_IRQ_MASTER1_SET))
+ goto done;
+
+ ret = pm8821_read_master_irq(chip, 1, &master);
+ if (ret) {
+ pr_err("Failed to read master 1 ret=%d\n", ret);
+ return;
+ }
+
+ pm8821_irq_read_master(chip, 1, master);
+
+done:
+ chained_irq_exit(irq_chip, desc);
+}
+
static void pm8xxx_irq_mask_ack(struct irq_data *d)
{
struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
@@ -254,13 +394,15 @@ static int pm8xxx_irq_get_irqchip_state(struct irq_data *d,
irq_bit = pmirq % 8;
spin_lock(&chip->pm_irq_lock);
- rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, block);
+ rc = regmap_write(chip->regmap, chip->irq_reg_base +
+ SSBI_REG_ADDR_IRQ_BLK_SEL, block);
if (rc) {
pr_err("Failed Selecting Block %d rc=%d\n", block, rc);
goto bail;
}
- rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
+ rc = regmap_read(chip->regmap, chip->irq_reg_base +
+ SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
if (rc) {
pr_err("Failed Reading Status rc=%d\n", rc);
goto bail;
@@ -299,6 +441,151 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
.map = pm8xxx_irq_domain_map,
};
+static void pm8821_irq_mask_ack(struct irq_data *d)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ unsigned int base, pmirq = irqd_to_hwirq(d);
+ u8 block, master;
+ int irq_bit, rc;
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ if (!master)
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
+ else
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
+
+ spin_lock(&chip->pm_irq_lock);
+ rc = regmap_update_bits(chip->regmap,
+ base + PM8821_IRQ_MASK_REG_OFFSET + block,
+ BIT(irq_bit), BIT(irq_bit));
+
+ if (rc) {
+ pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
+ goto fail;
+ }
+
+ rc = regmap_update_bits(chip->regmap,
+ base + PM8821_IRQ_CLEAR_OFFSET + block,
+ BIT(irq_bit), BIT(irq_bit));
+
+ if (rc) {
+ pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
+ pmirq, rc);
+ }
+
+fail:
+ spin_unlock(&chip->pm_irq_lock);
+}
+
+static void pm8821_irq_unmask(struct irq_data *d)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ unsigned int base, pmirq = irqd_to_hwirq(d);
+ int irq_bit, rc;
+ u8 block, master;
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ if (!master)
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
+ else
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
+
+ spin_lock(&chip->pm_irq_lock);
+
+ rc = regmap_update_bits(chip->regmap,
+ base + PM8821_IRQ_MASK_REG_OFFSET + block,
+ BIT(irq_bit), ~BIT(irq_bit));
+
+ if (rc)
+ pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
+
+ spin_unlock(&chip->pm_irq_lock);
+}
+
+static int pm8821_irq_set_type(struct irq_data *d, unsigned int flow_type)
+{
+
+ /*
+ * PM8821 IRQ controller does not have explicit software support for
+ * IRQ flow type.
+ */
+ return 0;
+}
+
+static int pm8821_irq_get_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which,
+ bool *state)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ int pmirq, rc;
+ u8 block, irq_bit, master;
+ unsigned int bits;
+ unsigned int base;
+ unsigned long flags;
+
+ pmirq = irqd_to_hwirq(d);
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ if (!master)
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
+ else
+ base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
+
+ spin_lock_irqsave(&chip->pm_irq_lock, flags);
+
+ rc = regmap_read(chip->regmap,
+ base + PM8821_IRQ_RT_STATUS_OFFSET + block, &bits);
+ if (rc) {
+ pr_err("Failed Reading Status rc=%d\n", rc);
+ goto bail_out;
+ }
+
+ *state = !!(bits & BIT(irq_bit));
+
+bail_out:
+ spin_unlock_irqrestore(&chip->pm_irq_lock, flags);
+
+ return rc;
+}
+
+static struct irq_chip pm8821_irq_chip = {
+ .name = "pm8821",
+ .irq_mask_ack = pm8821_irq_mask_ack,
+ .irq_unmask = pm8821_irq_unmask,
+ .irq_set_type = pm8821_irq_set_type,
+ .irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
+ .flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
+};
+
+static int pm8821_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct pm_irq_chip *chip = d->host_data;
+
+ irq_set_chip_and_handler(irq, &pm8821_irq_chip, handle_level_irq);
+ irq_set_chip_data(irq, chip);
+ irq_set_noprobe(irq);
+
+ return 0;
+}
+
+static const struct irq_domain_ops pm8821_irq_domain_ops = {
+ .xlate = irq_domain_xlate_twocell,
+ .map = pm8821_irq_domain_map,
+};
+
static const struct regmap_config ssbi_regmap_config = {
.reg_bits = 16,
.val_bits = 8,
@@ -308,10 +595,25 @@ static const struct regmap_config ssbi_regmap_config = {
.reg_write = ssbi_reg_write
};
+static const struct pm8xxx_data pm8xxx_data = {
+ .num_irqs = PM8921_NR_IRQS,
+ .irq_reg_base = SSBI_REG_ADDR_IRQ_BASE,
+ .irq_domain_ops = &pm8xxx_irq_domain_ops,
+ .irq_handler = pm8xxx_irq_handler,
+};
+
+static const struct pm8xxx_data pm8821_data = {
+ .num_irqs = PM8821_NR_IRQS,
+ .irq_reg_base = SSBI_PM8821_REG_ADDR_IRQ_BASE,
+ .irq_domain_ops = &pm8821_irq_domain_ops,
+ .irq_handler = pm8821_irq_handler,
+};
+
static const struct of_device_id pm8921_id_table[] = {
- { .compatible = "qcom,pm8018", },
- { .compatible = "qcom,pm8058", },
- { .compatible = "qcom,pm8921", },
+ { .compatible = "qcom,pm8018", .data = &pm8xxx_data},
+ { .compatible = "qcom,pm8058", .data = &pm8xxx_data},
+ { .compatible = "qcom,pm8821", .data = &pm8821_data},
+ { .compatible = "qcom,pm8921", .data = &pm8xxx_data},
{ }
};
MODULE_DEVICE_TABLE(of, pm8921_id_table);
@@ -319,11 +621,17 @@ MODULE_DEVICE_TABLE(of, pm8921_id_table);
static int pm8921_probe(struct platform_device *pdev)
{
struct regmap *regmap;
+ const struct pm8xxx_data *data;
int irq, rc;
unsigned int val;
u32 rev;
struct pm_irq_chip *chip;
- unsigned int nirqs = PM8921_NR_IRQS;
+
+ data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
+ if (!data) {
+ dev_err(&pdev->dev, "No matching driver data found\n");
+ return -EINVAL;
+ }
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -354,25 +662,27 @@ static int pm8921_probe(struct platform_device *pdev)
rev |= val << BITS_PER_BYTE;
chip = devm_kzalloc(&pdev->dev, sizeof(*chip) +
- sizeof(chip->config[0]) * nirqs,
- GFP_KERNEL);
+ sizeof(chip->config[0]) * data->num_irqs,
+ GFP_KERNEL);
if (!chip)
return -ENOMEM;
platform_set_drvdata(pdev, chip);
chip->regmap = regmap;
- chip->num_irqs = nirqs;
+ chip->num_irqs = data->num_irqs;
+ chip->irq_reg_base = data->irq_reg_base;
chip->num_blocks = DIV_ROUND_UP(chip->num_irqs, 8);
chip->num_masters = DIV_ROUND_UP(chip->num_blocks, 8);
spin_lock_init(&chip->pm_irq_lock);
- chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node, nirqs,
- &pm8xxx_irq_domain_ops,
+ chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
+ data->num_irqs,
+ data->irq_domain_ops,
chip);
if (!chip->irqdomain)
return -ENODEV;
- irq_set_chained_handler_and_data(irq, pm8xxx_irq_handler, chip);
+ irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
irq_set_irq_wake(irq, 1);
rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
--
2.10.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-08 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 1dbe697..fde006c 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -627,6 +627,34 @@
clock-names = "core";
};
+ qcom,ssbi at c00000 {
+ compatible = "qcom,ssbi";
+ reg = <0x00c00000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+
+ pmicintc2: pmic at 1 {
+ compatible = "qcom,pm8821";
+ interrupt-parent = <&tlmm_pinmux>;
+ interrupts = <76 8>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8821_mpps: mpps at 50 {
+
+ compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
+ reg = <0x50>;
+
+ interrupts = <24 1>, <25 1>, <26 1>,
+ <27 1>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+
qcom,ssbi at 500000 {
compatible = "qcom,ssbi";
reg = <0x00500000 0x1000>;
--
2.10.1
^ permalink raw reply related
* [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
From: Marcin Wojtas @ 2016-11-08 16:31 UTC (permalink / raw)
To: linux-arm-kernel
Enabling SPI controllers, which are attached to different busses
inside an SoC, may result in overlapping enumeration and cause
sysfs registration failure. Example log after enabling two
controllers on Armada 8040 SoC with same identifiers:
[ 3.740415] sysfs: cannot create duplicate filename
'/class/spi_master/spi0'
[ 3.747510] ------------[ cut here ]------------
[ 3.752145] WARNING: at fs/sysfs/dir.c:31
[...]
[ 4.002299] orion_spi: probe of f4700600.spi failed with error -17
spi-orion driver offers dedicated DT property ('cell-index'), that
allow setting unique identifiers. Recently added support for CP110-slave
HW block introduced two new SPI controllers' nodes with same ID as
ones from CP110-master.
This commit fixes the issue by assigning different 'cell-index' values
for CP110-slave SPI controllers.
Fixes: 4eef78a0091b ("arm64: dts: marvell: add description for the slave
CP110 in Armada 8K")
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index abb3fa2..d94d592 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -132,7 +132,7 @@
reg = <0x700600 0x50>;
#address-cells = <0x1>;
#size-cells = <0x0>;
- cell-index = <1>;
+ cell-index = <3>;
clocks = <&cps_syscon0 1 21>;
status = "disabled";
};
@@ -142,7 +142,7 @@
reg = <0x700680 0x50>;
#address-cells = <1>;
#size-cells = <0>;
- cell-index = <2>;
+ cell-index = <4>;
clocks = <&cps_syscon0 1 21>;
status = "disabled";
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH] arm64: dts: marvell: Fix typo in label name on Armada 37xx
From: Gregory CLEMENT @ 2016-11-08 16:32 UTC (permalink / raw)
To: linux-arm-kernel
The label names of the peripheral clocks have a typo. Fix it before it is
more widely used.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c4762538ec01..693c36ac2c70 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -105,7 +105,7 @@
status = "disabled";
};
- nb_perih_clk: nb-periph-clk at 13000{
+ nb_periph_clk: nb-periph-clk at 13000{
compatible = "marvell,armada-3700-periph-clock-nb";
reg = <0x13000 0x100>;
clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
@@ -113,7 +113,7 @@
#clock-cells = <1>;
};
- sb_perih_clk: sb-periph-clk at 18000{
+ sb_periph_clk: sb-periph-clk at 18000{
compatible = "marvell,armada-3700-periph-clock-sb";
reg = <0x18000 0x100>;
clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
--
2.10.1
^ permalink raw reply related
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: John Garry @ 2016-11-08 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108161245.GD20591@arm.com>
On 08/11/2016 16:12, Will Deacon 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.
>>
>> 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.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/Kconfig | 6 +++
>> arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
>> arch/arm64/include/asm/io.h | 29 +++++++++++++
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/extio.c | 27 ++++++++++++
>> 5 files changed, 157 insertions(+)
>> create mode 100644 arch/arm64/include/asm/extio.h
>> create mode 100644 arch/arm64/kernel/extio.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 969ef88..b44070b 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
>> config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> default 16
>>
>> +config ARM64_INDIRECT_PIO
>> + bool "access peripherals with legacy I/O port"
>> + help
>> + Support special accessors for ISA I/O devices. This is needed for
>> + SoCs that do not support standard read/write for the ISA range.
>> +
>> config NO_IOPORT_MAP
>> def_bool y if !PCI
>>
>> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
>> new file mode 100644
>> index 0000000..6ae0787
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/extio.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __LINUX_EXTIO_H
>> +#define __LINUX_EXTIO_H
>> +
>> +struct extio_ops {
>> + unsigned long start;/* inclusive, sys io addr */
>> + unsigned long end;/* inclusive, sys io addr */
>> +
>> + u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
>> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
>> + size_t dlen);
>> + u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
>> + size_t dlen, unsigned int count);
>> + void (*pfouts)(void *devobj, unsigned long ptaddr,
>> + const void *outbuf, size_t dlen,
>> + unsigned int count);
>> + void *devpara;
>> +};
>> +
>> +extern struct extio_ops *arm64_extio_ops;
>> +
>> +#define DECLARE_EXTIO(bw, type) \
>> +extern type in##bw(unsigned long addr); \
>> +extern void out##bw(type value, unsigned long addr); \
>> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
>> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
>> +
>> +#define BUILD_EXTIO(bw, type) \
>> +type in##bw(unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + return read##bw(PCI_IOBASE + addr); \
>> + return arm64_extio_ops->pfin ? \
>> + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
>> + addr, sizeof(type)) : -1; \
>> +} \
>> + \
>> +void out##bw(type value, unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + write##bw(value, PCI_IOBASE + addr); \
>> + else \
>> + if (arm64_extio_ops->pfout) \
>> + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>> + addr, value, sizeof(type)); \
>> +} \
>> + \
>> +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + reads##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfins) \
>> + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +} \
>> + \
>> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + writes##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfouts) \
>> + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +}
>> +
>> +static inline void arm64_set_extops(struct extio_ops *ops)
>> +{
>> + if (ops)
>> + WRITE_ONCE(arm64_extio_ops, ops);
>
> Why does this need to be WRITE_ONCE? You don't have READ_ONCE on the reader
> side. Also, what if multiple drivers want to set different ops for distinct
> address ranges?
I think that the idea here is that we only have possibly one master in
the system which offers indirectIO backend, so another one could not
possibly re-set this value.
>
>> +}
>> +
>> +#endif /* __LINUX_EXTIO_H*/
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0bba427..136735d 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -31,6 +31,7 @@
>> #include <asm/early_ioremap.h>
>> #include <asm/alternative.h>
>> #include <asm/cpufeature.h>
>> +#include <asm/extio.h>
>>
>> #include <xen/xen.h>
>>
>> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>
>> +
>> +/*
>> + * redefine the in(s)b/out(s)b for indirect-IO.
>> + */
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define inb inb
>> +#define outb outb
>> +#define insb insb
>> +#define outsb outsb
>> +/* external declaration */
>> +DECLARE_EXTIO(b, u8)
>> +
>> +#define inw inw
>> +#define outw outw
>> +#define insw insw
>> +#define outsw outsw
>> +
>> +DECLARE_EXTIO(w, u16)
>> +
>> +#define inl inl
>> +#define outl outl
>> +#define insl insl
>> +#define outsl outsl
>> +
>> +DECLARE_EXTIO(l, u32)
>> +#endif
>> +
>> +
>> /*
>> * String version of I/O memory access operations.
>> */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 7d66bba..60e0482 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
>> sys_compat.o entry32.o
>> arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
>> arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
>> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
>> arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
>> arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
>> arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> new file mode 100644
>> index 0000000..647b3fa
>> --- /dev/null
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/io.h>
>> +
>> +struct extio_ops *arm64_extio_ops;
>> +
>> +
>> +BUILD_EXTIO(b, u8)
>> +
>> +BUILD_EXTIO(w, u16)
>> +
>> +BUILD_EXTIO(l, u32)
>
> Is there no way to make this slightly more generic, so that it can be
> re-used elsewhere? For example, if struct extio_ops was common, then
> you could have the singleton (which maybe should be an interval tree?),
> type definition, setter function and the BUILD_EXTIO invocations
> somewhere generic, rather than squirelled away in the arch backend.
>
> Will
The concern would be that some architecture which uses generic
higher-level ISA accessor ops, but have IO space, could be affected.
John
>
> .
>
^ 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