* [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 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 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
* [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 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
* 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
* [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
* [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
* [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 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
* [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 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
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28decdc3-6b86-924f-d3c1-9873a8cfce77@arm.com>
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.
> 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?
> 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:
ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872
ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016
Time : 15:18:35
Date : 08:11:2016
Cmd> usb_on
Enabling debug USB...
Cmd> reboot
Powering up system...
Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp : 26 degC
Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA config: PASSED
OSC CLK config: PASSED
Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2
Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1
Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000
Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000
Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000
Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000
Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000
Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000
Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000
Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...
Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118 test: PASSED
KMI1/2 test: PASSED
MMC test: PASSED
PB/LEDs test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED
SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.
SoC SMB clock enabled.
Testing SMB clock...
SMB clock running
Releasing system resets...
UART0 set to SoC UART0
UART1 set to SoC UART1
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.2(debug):99e8937
NOTICE: BL1: Built : 12:57:25, Nov 1 2016
INFO: BL1: RAM 0x4037000 - 0x4040000
INFO: Using crypto library 'mbed TLS'
INFO: BL1: Loading BL2
INFO: Loading image id=6 at address 0x4006000
INFO: Skip reserving region [base = 0x4006000, size = 0x37f]
INFO: Image id=6 loaded at address 0x4006000, size = 0x37f
INFO: Loading image id=1 at address 0x4006000
INFO: Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE: BL1: Booting BL2
INFO: Entry point address = 0x4006000
INFO: SPSR = 0x3c5
NOTICE: BL2: v1.2(debug):99e8937
NOTICE: BL2: Built : 12:57:25, Nov 1 2016
INFO: Using crypto library 'mbed TLS'
INFO: BL2: Loading SCP_BL2
INFO: Loading image id=7 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO: Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO: Loading image id=8 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x47a]
INFO: Image id=8 loaded at address 0x4023000, size = 0x47a
INFO: Loading image id=12 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x389]
INFO: Image id=12 loaded at address 0x4023000, size = 0x389
INFO: Loading image id=2 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0xf334]
INFO: Image id=2 loaded at address 0x4023000, size = 0xf334
INFO: BL2: Initiating SCP_BL2 transfer to SCP
INFO: BL2: SCP_BL2 transferred to SCP
INFO: Configuring TrustZone Controller
INFO: BL2: Loading BL31
INFO: Loading image id=9 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x47a]
INFO: Image id=9 loaded at address 0x4023000, size = 0x47a
INFO: Loading image id=13 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x389]
INFO: Image id=13 loaded at address 0x4023000, size = 0x389
INFO: Loading image id=3 at address 0x4023000
INFO: Image id=3 loaded at address 0x4023000, size = 0xc020
INFO: BL2: Loading BL32
INFO: Loading image id=10 at address 0xff000000
INFO: Skip reserving region [base = 0xff000000, size = 0x488]
INFO: Image id=10 loaded at address 0xff000000, size = 0x488
INFO: Loading image id=14 at address 0xff000000
INFO: Skip reserving region [base = 0xff000000, size = 0x397]
INFO: Image id=14 loaded at address 0xff000000, size = 0x397
INFO: Loading image id=4 at address 0xff000000
INFO: Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO: BL2: Loading BL33
INFO: Loading image id=11 at address 0xe0000000
INFO: Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO: Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO: Loading image id=15 at address 0xe0000000
INFO: Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO: Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO: Loading image id=5 at address 0xe0000000
INFO: Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE: BL1: Booting BL31
INFO: Entry point address = 0x4023000
INFO: SPSR = 0x3cd
NOTICE: BL31: v1.2(debug):99e8937
NOTICE: BL31: Built : 12:57:25, Nov 1 2016
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: Initializing BL32
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0xe0000000
INFO: SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov 1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
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.
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.
--
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 RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Charles Keepax @ 2016-11-08 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-2-git-send-email-s.nawrocki@samsung.com>
On Fri, Nov 04, 2016 at 05:14:47PM +0100, Sylwester Nawrocki wrote:
> This patch series aims to convert the s3c64xx platform to use
> the new universal DMA channel request API, i.e. this is only
> meaningful for non-dt systems using s3c64xx SoCs.
>
> I'm sending the whole series as RFC since I didn't test it
> yet, I'm going to prepare smd6410 for testing this series.
> It would be great if someone else could also test it,
> either SPI or sound functionality verification would be
> useful.
>
> Then we could queue the first two patches in this series
> for v4.10-rc1 and the remaining patches for subsequent
> release.
>
> The whole series can be pulled from git repository:
> git://linuxtv.org/snawrocki/samsung.git
> branch: for-v4.10/dma/pl080-s3c64xx
>
> Thanks.
>
> Sylwester Nawrocki (7):
> dma: pl08x: Add support for the DMA slave map
> ARM: S3C64XX: Add DMA slave maps for PL080 devices
> spi: s3c64xx: Do not use platform_data for DMA parameters
> ASoC: samsung: i2s: Do not use platform_data for DMA parameters
> ASoC: samsung: pcm: Do not use platform_data for DMA parameters
> ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
> ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
> fields
>
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,
Charles
^ permalink raw reply
* [PATCH RFC 00/12] tda998x updates
From: Robin Murphy @ 2016-11-08 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108133411.GA31754@n2100.armlinux.org.uk>
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.
Robin.
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 1b262a89b7e1..3a5e5c466972 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -43,12 +43,12 @@ struct tda998x_priv {
> u16 rev;
> u8 current_page;
> bool is_on;
> - bool is_hdmi_sink;
> - bool is_hdmi_config;
> + bool supports_infoframes;
> + bool sink_has_audio;
> u8 vip_cntrl_0;
> u8 vip_cntrl_1;
> u8 vip_cntrl_2;
> - unsigned long tdms_clock;
> + unsigned long tmds_clock;
> struct tda998x_audio_params audio_params;
>
> struct platform_device *audio_pdev;
> @@ -774,7 +774,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> * assume 100MHz requires larger divider.
> */
> adiv = AUDIO_DIV_SERCLK_8;
> - if (priv->tdms_clock > 100000)
> + if (priv->tmds_clock > 100000)
> adiv++; /* AUDIO_DIV_SERCLK_16 */
>
> /* S/PDIF asks for a larger divider */
> @@ -869,8 +869,7 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
> }
>
> mutex_lock(&priv->audio_mutex);
> - /* We must not program the TDA998x for audio if the sink is DVI. */
> - if (priv->is_hdmi_config)
> + if (priv->supports_infoframes && priv->sink_has_audio)
> ret = tda998x_configure_audio(priv, &audio);
> else
> ret = 0;
> @@ -962,6 +961,27 @@ static int tda998x_connector_dpms(struct drm_connector *connector, int mode)
> return drm_helper_connector_dpms(connector, mode);
> }
>
> +static int tda998x_connector_fill_modes(struct drm_connector *connector,
> + uint32_t maxX, uint32_t maxY)
> +{
> + struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
> + int ret;
> +
> + mutex_lock(&priv->audio_mutex);
> + ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> +
> + if (connector->edid_blob_ptr) {
> + struct edid *edid = (void *)connector->edid_blob_ptr->data;
> +
> + priv->sink_has_audio = drm_detect_monitor_audio(edid);
> + } else {
> + priv->sink_has_audio = false;
> + }
> + mutex_unlock(&priv->audio_mutex);
> +
> + return ret;
> +}
> +
> static enum drm_connector_status
> tda998x_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -980,7 +1000,7 @@ static void tda998x_connector_destroy(struct drm_connector *connector)
> static const struct drm_connector_funcs tda998x_connector_funcs = {
> .dpms = tda998x_connector_dpms,
> .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> + .fill_modes = tda998x_connector_fill_modes,
> .detect = tda998x_connector_detect,
> .destroy = tda998x_connector_destroy,
> .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> @@ -1072,11 +1092,7 @@ static int tda998x_connector_get_modes(struct drm_connector *connector)
>
> drm_mode_connector_update_edid_property(connector, edid);
> n = drm_add_edid_modes(connector, edid);
> - priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
> -
> - mutex_lock(&priv->audio_mutex);
> drm_edid_to_eld(connector, edid);
> - mutex_unlock(&priv->audio_mutex);
>
> kfree(edid);
>
> @@ -1350,8 +1366,22 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> /* must be last register set: */
> reg_write(priv, REG_TBG_CNTRL_0, 0);
>
> - /* Only setup the info frames if the sink is HDMI */
> - if (priv->is_hdmi_sink) {
> + priv->tmds_clock = adjusted_mode->clock;
> +
> + /* CEA-861B section 6 says that:
> + * CEA version 1 (CEA-861) has no support for infoframes.
> + * CEA version 2 (CEA-861A) supports version 1 AVI infoframes,
> + * and optional basic audio.
> + * CEA version 3 (CEA-861B) supports version 1 and 2 AVI infoframes,
> + * and optional digital audio, with audio infoframes.
> + *
> + * Since we only support generation of version 2 AVI infoframes,
> + * ignore CEA version 2 and below (iow, behave as if we're a
> + * CEA-861 source.)
> + */
> + priv->supports_infoframes = priv->connector.display_info.cea_rev >= 3;
> +
> + if (priv->supports_infoframes) {
> /* We need to turn HDMI HDCP stuff on to get audio through */
> reg &= ~TBG_CNTRL_1_DWIN_DIS;
> reg_write(priv, REG_TBG_CNTRL_1, reg);
> @@ -1360,13 +1390,11 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
>
> tda998x_write_avi(priv, adjusted_mode);
>
> - priv->tdms_clock = adjusted_mode->clock;
> -
> - if (priv->audio_params.format != AFMT_UNUSED)
> + if (priv->audio_params.format != AFMT_UNUSED &&
> + priv->sink_has_audio)
> tda998x_configure_audio(priv, &priv->audio_params);
> }
>
> - priv->is_hdmi_config = priv->is_hdmi_sink;
> mutex_unlock(&priv->audio_mutex);
> }
>
>
>
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-08 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1609380.NN50qvVsP7@wuerfel>
On 08/11/2016 15:10, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
>>
>> Hi Arnd,
>>
>> Thanks for the reference.
>>
>> I think the i2c interface doesn't fully satisfy our requirements as we
>> need more than just a slave bus address when accessing the slave device
>> (which I think is what i2c uses). We also need to pass "offset" and
>> "mod_mask" arguments to the djtag adapter to access specific registers
>> in the slave device.
>
> Ok. Are those values constant per device, or maybe a range? We may want to
> include those in the reg property as well then.
>
> Arnd
>
Hi Arnd,
I'm not sure, I'll defer to Tan/Anurup.
Cheers,
John
>
> .
>
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-08 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108145118.GR1041@n2100.armlinux.org.uk>
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.
> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>
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.
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.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Arnd Bergmann @ 2016-11-08 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2bac1a34-591b-6557-15bf-40db25c3d129@huawei.com>
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
>
> Hi Arnd,
>
> Thanks for the reference.
>
> I think the i2c interface doesn't fully satisfy our requirements as we
> need more than just a slave bus address when accessing the slave device
> (which I think is what i2c uses). We also need to pass "offset" and
> "mod_mask" arguments to the djtag adapter to access specific registers
> in the slave device.
Ok. Are those values constant per device, or maybe a range? We may want to
include those in the reg property as well then.
Arnd
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Arnd Bergmann @ 2016-11-08 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5821D736.7080803@gmail.com>
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
> >>>> If these are backwards compatible, just mark them as compatible in DT,
> >>>> e.g. hip06 can use
> >>>>
> >>>> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
> >>>>
> >>>> so you can tell the difference if you need to, but the driver only has to
> >>>> list the oldest one here.
> >>>>
> >>>> What is the difference between the cpu and io djtag interfaces?
> >> On some chips like hip06, the djtag version is different for IO die.
> > In what way? The driver doesn't seem to care about the difference.
> There is a difference in djtag version of CPU and IO die (in some chips).
> For ex: in hip06 djtag for CPU is v1 and for IO is v2.
> so they use different readwrite handlers djtag_readwrite_(v1/2).
>
> + /* for hip06(D03) cpu die */
> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
> + .data = (void *)djtag_readwrite_v1 },
> + /* for hip06(D03) io die */
> + { .compatible = "hisilicon,hip06-io-djtag-v2",
> + .data = (void *)djtag_readwrite_v2 },
>
>
> For the same djtag version, there is no difference in handling in the
> driver.
Right, but my point was about the compatibility with the older chips
using the same IP block, marking the ones as compatible that actually
use the same interface.
I also see that the compatible strings have the version included in
them, and you can probably drop them by requiring them only in the
fallback:
compatible = "hisilicon,hip05-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip05-io-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-cpu-djtag", "hisilicon,djtag-v1";
compatible = "hisilicon,hip06-io-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-cpu-djtag", "hisilicon,djtag-v2";
compatible = "hisilicon,hip07-io-djtag", "hisilicon,djtag-v2";
We want to have the first entry be as specific as possible, but
the last (second) entry is the one that can be used by the driver
for matching. When a future hip08/hip09/... chip uses an existing
interface, you then don't have to update the driver.
Arnd
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-08 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108144445.GD1575@localhost.localdomain>
On Tue, Nov 08, 2016 at 02:44:45PM +0000, Charles Keepax wrote:
> On Fri, Nov 04, 2016 at 05:14:49PM +0100, Sylwester Nawrocki wrote:
> > This patch adds DMA slave map tables to the pl080 devices's
> > platform_data in order to support the new channel request API.
> > A few devices for which there was no DMA support with current
> > code are omitted from the tables.
> >
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > ---
> > arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> >
> > 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.
Thanks,
Charles
^ permalink raw reply
* [PATCH] iommu/dma-iommu: properly respect configured address space size
From: Marek Szyprowski @ 2016-11-08 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d215c05c-b922-4bee-a2dc-695669a801f6@arm.com>
Hi Robin,
On 2016-11-08 15:44, Robin Murphy wrote:
> On 08/11/16 13:41, Marek Szyprowski wrote:
>> On 2016-11-08 12:37, Robin Murphy wrote:
>>> On 07/11/16 13:06, Marek Szyprowski wrote:
>>>> When one called iommu_dma_init_domain() with size smaller than device's
>>>> DMA mask, the alloc_iova() will not respect it and always assume that
>>>> all
>>>> IOVA addresses will be allocated from the the (base ...
>>>> dev->dma_mask) range.
>>> Is that actually a problem for anything?
>> Yes, I found this issue while working on next version of ARM & ARM64
>> DMA-mapping/IOMMU integration patchset and adapting Exynos drivers for the
>> new IOMMU/DMA-mapping glue.
>>
>> Some Exynos devices (codec and camera isp) operate only on the limited (and
>> really small: 256M for example) DMA window. They use non-standard way of
>> addressing memory: an offset from the firmware base. However they still
>> have
>> 32bit DMA mask, as the firmware can be located basically everywhere in the
>> real DMA address space, but then they can access only next 256M from that
>> firmware base.
> OK, that's good to know, thanks. However, I think in this case it sounds
> like it's really the DMA mask that's the underlying problem - if those
> blocks themselves can only drive 28 address bits, then the struct
> devices representing them should have 28-bit DMA masks, and the
> "firmware base" of whoever's driving the upper bits modelled with a
> dma_pfn_offset. Even if they do have full 32-bit interfaces themselves,
> but are constrained to segment-offset addressing internally, I still
> think it would be tidier to represent things that way.
>
> At some point in dma-iommu development I did have support for DMA
> offsets upstream of the IOMMU, and am happy to reinstate it if there's a
> real use case (assuming you can't simply always set the firmware base to
> 0 when using the IOMMU).
That would indeed look a bit simpler, but I've already tried such approach
and the firmware crashes when its base in real DMA address space is set to
zero.
>>>> This patch fixes this issue by taking the configured address space size
>>>> parameter into account (if it is smaller than the device's dma_mask).
>>> TBH I've been pondering ripping the size stuff out of dma-iommu, as it
>>> all stems from me originally failing to understand what dma_32bit_pfn is
>>> actually for. The truth is that iova_domains just don't have a size or
>>> upper limit; however if devices with both large and small DMA masks
>>> share a domain, then the top-down nature of the allocator means that
>>> allocating for the less-capable devices would involve walking through
>>> every out-of-range entry in the tree every time. Having cached32_node
>>> based on dma_32bit_pfn just provides an optimised starting point for
>>> searching within the smaller mask.
>> Right, this dma_32bit_pfn was really misleading at the first glance,
>> but then I found that this was something like end_pfn in case of dma-iommu
>> code.
> Yes, that was my incorrect assumption - at the time I interpreted it as
> a de-facto upper limit which was still possible to allocate above in
> special circumstances, which turns out to be almost entirely backwards.
> I'd rather not bake that into the dma-iommu code any further if we can
> avoid it (I'll try throwing an RFC together to clear up what's there
> already).
Okay.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-1-git-send-email-sudeep.holla@arm.com>
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?
(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)
--
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 v2 0/5] ARM: da850: new drivers for better LCDC support
From: Sekhar Nori @ 2016-11-08 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-1-git-send-email-bgolaszewski@baylibre.com>
+ Arnd, Olof
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> This series adds two new drivers in order to better support the LCDC
> rev1 present on the da850 boards.
>
> The first patch adds a new memory driver which allows to write to the
> DDR2/mDDR memory controller present on the da8xx SoCs.
>
> The second patch adds a new bus driver which allows to interact with
> the MSTPRI registers of the SYSCFG0 module
I think patches 1/5 and 2/5 are ready to be merged. If there are no
objections I would like to send a pull request for them to be merged
through ARM-SoC tree for v4.10 kernel.
Thanks,
Sekhar
>
> As is mentioned in the comments: we don't want to commit to supporting
> stable interfaces (DT bindings or sysfs attributes) so we hardcode the
> settings required by some boards (for now only da850-lcdk) with the
> hope that linux gets an appropriate framework for performance knobs
> in the future.
>
> Potential extensions of these drivers should be straightforward in the
> future.
>
> Subsequent patches add DT nodes for the new drivers: disabled nodes
> in da850.dtsi and enabled in da850-lcdk.dts.
>
> The last patch adds a workaround for current lack of support for drm
> bridges in tilcdc.
>
> Tested on a da850-lcdk with a display connected over VGA and two
> additional patches for tilcdc (sent to linux-drm): ran simple modetest
> for supported resolutions, used X.org and fluxbox as graphical
> environment, played video with mplayer.
>
> v1 -> v2:
> - used regular readl()/writel() instead of __raw_** versions
> - used resource_size() instead of calculating the size by hand
> - used ioremap instead of syscon in patch [2/5]
> - added the DT nodes in patches [3/5]-[5/5]
>
> Bartosz Golaszewski (5):
> ARM: memory: da8xx-ddrctl: new driver
> ARM: bus: da8xx-mstpri: new driver
> ARM: dts: da850: add the mstpri and ddrctl nodes
> ARM: dts: da850-lcdk: enable mstpri and ddrctl nodes
> ARM: dts: da850-lcdk: add tilcdc panel node
>
> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 ++
> arch/arm/boot/dts/da850-lcdk.dts | 71 ++++++
> arch/arm/boot/dts/da850.dtsi | 11 +
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 2 +
> drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 ++++++++++++++
> 10 files changed, 586 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> create mode 100644 drivers/bus/da8xx-mstpri.c
> create mode 100644 drivers/memory/da8xx-ddrctl.c
>
^ permalink raw reply
* [PATCH 0/5] ARM: OMAP: dead code removal
From: Tony Lindgren @ 2016-11-08 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKP5S=05P4p7qBXtHZepQ7Xchuj-2FZdVXiy+FBjTv9WRxhCsw@mail.gmail.com>
* Nicolae Rosia <nicolae.rosia.oss@gmail.com> [161107 23:56]:
> On Wed, Nov 2, 2016 at 2:51 PM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> > I think the commit logs for these patches
> > need a little detail on why the code is
> > no longer needed. For posterity.
> Hi,
>
> Thanks, I have updated the series but I unfortunately I've sent it as
> a reply to the old thread.
That's fine, I've tagged it for next but have not applied
yet.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-08 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-4-git-send-email-s.nawrocki@samsung.com>
On Fri, Nov 04, 2016 at 05:14:49PM +0100, Sylwester Nawrocki wrote:
> This patch adds DMA slave map tables to the pl080 devices's
> platform_data in order to support the new channel request API.
> A few devices for which there was no DMA support with current
> code are omitted from the tables.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> 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?
> @@ -224,6 +254,8 @@ struct pl08x_platform_data s3c64xx_dma1_plat_data = {
> .put_xfer_signal = pl08x_put_xfer_signal,
> .slave_channels = s3c64xx_dma1_info,
> .num_slave_channels = ARRAY_SIZE(s3c64xx_dma1_info),
> + .slave_map = s3c64xx_dma1_slave_map,
> + .slavecnt = ARRAY_SIZE(s3c64xx_dma1_slave_map),
> };
ditto.
Thanks,
Charles
^ 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