* No subject
@ 2012-11-11 14:16 Sammy Chan
0 siblings, 0 replies; 88+ messages in thread
From: Sammy Chan @ 2012-11-11 14:16 UTC (permalink / raw)
To: linux-arm-kernel
http://ncompass1.altervista.org/wp-content/plugins/zgstplauaao/ugoogle.html
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
2018-07-06 21:16 ` Santosh Shilimkar
@ 2018-07-06 21:18 ` Santosh Shilimkar
0 siblings, 0 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:18 UTC (permalink / raw)
To: linux-arm-kernel
Ignore this.. Will send again with subjects fixed
On 7/6/2018 2:16 PM, Santosh Shilimkar wrote:
> Subject: [GIT PULL 3/3] SOC: Driver updates for v4.19
>
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>
> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/soc_drivers_for_4.19
>
> for you to fetch changes up to 990c10091db318c7eb7e8935c86b6f7c01585015:
>
> soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused (2018-07-06 09:47:51 -0700)
>
> ----------------------------------------------------------------
> Keystone SOC driver update for 4.19
>
> - Add suspend/resume functionality to TI EMIF SRAM driver
> - Add wakeup M3 RTC self refresh support
> - Fix for the PM runtime ifdefs
>
> ----------------------------------------------------------------
> Arnd Bergmann (1):
> soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused
>
> Dave Gerlach (2):
> memory: ti-emif-sram: Add resume function to recopy sram code
> soc: ti: wkup_m3_ipc: Add wkup_m3_request_wake_src
>
> Keerthy (1):
> soc: ti: wkup_m3_ipc: Add rtc_only with ddr in self refresh mode support
>
> drivers/memory/ti-emif-pm.c | 33 +++++++++++++++++++
> drivers/soc/ti/wkup_m3_ipc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/wkup_m3_ipc.h | 9 ++++++
> 3 files changed, 118 insertions(+)
>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
@ 2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:18 ` Santosh Shilimkar
1 sibling, 1 reply; 88+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 3/3] SOC: Driver updates for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/soc_drivers_for_4.19
for you to fetch changes up to 990c10091db318c7eb7e8935c86b6f7c01585015:
soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused (2018-07-06 09:47:51 -0700)
----------------------------------------------------------------
Keystone SOC driver update for 4.19
- Add suspend/resume functionality to TI EMIF SRAM driver
- Add wakeup M3 RTC self refresh support
- Fix for the PM runtime ifdefs
----------------------------------------------------------------
Arnd Bergmann (1):
soc: ti: wkup_m3_ipc: mark PM functions as __maybe_unused
Dave Gerlach (2):
memory: ti-emif-sram: Add resume function to recopy sram code
soc: ti: wkup_m3_ipc: Add wkup_m3_request_wake_src
Keerthy (1):
soc: ti: wkup_m3_ipc: Add rtc_only with ddr in self refresh mode support
drivers/memory/ti-emif-pm.c | 33 +++++++++++++++++++
drivers/soc/ti/wkup_m3_ipc.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/wkup_m3_ipc.h | 9 ++++++
3 files changed, 118 insertions(+)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
2018-07-06 21:16 Santosh Shilimkar
@ 2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
1 sibling, 0 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 2/3] ARM: Keystone config update for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_config_for_4.19
for you to fetch changes up to 60e9343b355118e903a155135f0511918d69e3ac:
ARM: configs: keystone: Enable CONFIG_MMC_SDHCI_OMAP (2018-06-29 15:57:53 -0700)
----------------------------------------------------------------
ARM: Keystone config updates for 4.19
- Enable MMC support
- Enable Micrel and DP83867 phys
----------------------------------------------------------------
Kishon Vijay Abraham I (1):
ARM: configs: keystone: Enable CONFIG_MMC_SDHCI_OMAP
Murali Karicheri (1):
ARM: keystone: k2g: enable micrel and dp83867 phys
arch/arm/configs/keystone_defconfig | 5 +++++
1 file changed, 5 insertions(+)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
0 siblings, 2 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2018-07-06 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL 1/3] ARM: Keystone DTS update for v4.19
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.19
for you to fetch changes up to f7e8a182a41e791cca3d7a9e25adddf2908bddde:
ARM: dts: keystone-k2g-evm: Use sdhci-omap programming model (2018-06-29 15:57:27 -0700)
----------------------------------------------------------------
ARM: Keystone DTS updates for 4.19
- K2G NIC drriver support
- Enbale network support for K2G ICE and EVM boards
- Hardware Ring driver support for k2hk, k2l and k2e socs
- Add MMC supply for k2g EVM
----------------------------------------------------------------
Kishon Vijay Abraham I (2):
ARM: dts: keystone-k2g-evm: Add "vqmmc-supply" property for mmc0/mmc1
ARM: dts: keystone-k2g-evm: Use sdhci-omap programming model
Murali Karicheri (3):
ARM: dts: k2g: add dt bindings to support network driver
ARM: dts: keystone-k2g-evm: Enable netcp network driver
ARM: dts: keystone-k2g-ice: Enable netcp network driver
Vitaly Andrianov (3):
ARM: dts: k2hk: add dts node for k2hk hw_rng driver
ARM: dts: k2l: add dts node for k2l hw_rng driver
ARM: dts: k2e: add dts node for k2e hw_rng driver
arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 20 ++++
arch/arm/boot/dts/keystone-k2g-evm.dts | 63 +++++++++++++
arch/arm/boot/dts/keystone-k2g-ice.dts | 59 ++++++++++++
arch/arm/boot/dts/keystone-k2g-netcp.dtsi | 147 +++++++++++++++++++++++++++++
arch/arm/boot/dts/keystone-k2g.dtsi | 25 +++--
arch/arm/boot/dts/keystone-k2hk-netcp.dtsi | 20 ++++
arch/arm/boot/dts/keystone-k2l-netcp.dtsi | 20 ++++
7 files changed, 346 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/boot/dts/keystone-k2g-netcp.dtsi
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2018-06-23 21:08 David Lechner
0 siblings, 0 replies; 88+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
To: linux-arm-kernel
Date: Sat, 23 Jun 2018 15:43:59 -0500
Subject: [PATCH 0/8] New remoteproc driver for TI PRU
This series adds a new remoteproc driver for the TI Programmable Runtime Unit
(PRU) that is present in some TI Sitara processors. This code has been tested
working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
There are a couple of quirks that had to be worked around in order to get this
working. The PRU units have multiple memory maps. Notably, both the instruction
RAM and data RAM are at address 0x0. This caused the da_to_va callback to not
work because the same address could refer to two different locations. To work
around this, the first two patches add a "map" parameter to the da_to_va
callbacks so that we have an extra bit of information to make this distinction.
Also, on AM38xx we have to use pdata for accessing a reset since there is not
a reset controller. There are several other devices doing this, so the seems
the best way for now.
For anyone else who would like to test, I used the rpmsg-client-sample driver.
Just enable it in your kernel config. Then grab the appropriate firmware[1]
and put in in /lib/firmware/. Use sysfs to start and stop the PRU:
echo start > /sys/class/remoteproc<n>/state
echo stop > /sys/class/remoteproc<n>/state
[1]: firmware downloads:
AM18XX: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM18xx-PRU-rpmsg-client-sample.zip
AM335X: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM335x-PRU-rpmsg-client-sample.zip
David Lechner (8):
remoteproc: add map parameter to da_to_va
remoteproc: add page lookup for TI PRU to ELF loader
ARM: OMAP2+: add pdata quirks for PRUSS reset
dt-bindings: add bindings for TI PRU as remoteproc
remoteproc: new driver for TI PRU
ARM: davinci_all_defconfig: enable PRU remoteproc module
ARM: dts: da850: add node for PRUSS
ARM: dts: am33xx: add node for PRU remoteproc
.../bindings/remoteproc/ti_pru_rproc.txt | 51 ++
MAINTAINERS | 5 +
arch/arm/boot/dts/am33xx.dtsi | 9 +
arch/arm/boot/dts/da850.dtsi | 8 +
arch/arm/configs/davinci_all_defconfig | 2 +
arch/arm/mach-omap2/pdata-quirks.c | 9 +
drivers/remoteproc/Kconfig | 7 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/imx_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 3 +-
drivers/remoteproc/qcom_adsp_pil.c | 2 +-
drivers/remoteproc/qcom_q6v5_pil.c | 2 +-
drivers/remoteproc/qcom_wcnss.c | 2 +-
drivers/remoteproc/remoteproc_core.c | 10 +-
drivers/remoteproc/remoteproc_elf_loader.c | 117 +++-
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++
drivers/remoteproc/wkup_m3_rproc.c | 3 +-
include/linux/platform_data/ti-pruss.h | 18 +
include/linux/remoteproc.h | 2 +-
include/uapi/linux/elf-em.h | 1 +
22 files changed, 899 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
create mode 100644 drivers/remoteproc/ti_pru_rproc.c
create mode 100644 include/linux/platform_data/ti-pruss.h
--
2.17.1
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2018-05-04 20:06 Bjorn Helgaas
0 siblings, 0 replies; 88+ messages in thread
From: Bjorn Helgaas @ 2018-05-04 20:06 UTC (permalink / raw)
To: linux-arm-kernel
Bcc:
Subject: Re: [PATCH] PCI: Check whether bridges allow access to extended
config space
Reply-To:
In-Reply-To: <5AEC8002.5000309@kontron.com>
[+cc Fred, Sinan]
On Fri, May 04, 2018 at 03:45:07PM +0000, Gilles Buloz wrote:
> Le 04/05/2018 00:31, Bjorn Helgaas a ?crit :
> > [+cc LKML]
> >
> > On Thu, May 03, 2018 at 12:40:27PM +0000, Gilles Buloz wrote:
> >> Subject: [PATCH] For exception at PCI probe due to bridge reporting UR
> >>
> >> Even if a device supports extended config access, no such access must be
> >> done to this device If there's a bridge not supporting that in the path
> >> to this device. Doing such access with UR reporting enabled on the root
> >> bridge leads to an exception.
> >>
> >> This is the case on a LS1043A CPU (NXP QorIQ Layerscape) platform with
> >> the following bus topology :
> >> LS1043 PCIe root
> >> -> PEX8112 PCIe-to-PCI bridge (not supporting ext cfg on PCI side)
> >> -> PMC slot connector (for legacy PMC modules)
> >> With a PMC module topology as follows :
> >> PMC connector
> >> -> PCI-to-PCIe bridge
> >> -> PCIe switch (4 ports)
> >> -> 4 PCIe devices (one on each port)
> >> In this case all devices behind the PEX8112 are supporting extended config
> >> access but this is prohibited by the PEX8112. Without this patch, an
> >> exception (synchronous abort) occurs in pci_cfg_space_size_ext().
> >>
> >> This patch checks the parent bridge of each allocated child bus to know if
> >> extended config access is supported on the child bus, and sets a flag in
> >> child->bus_flags if not supported. This flag is inherited by all children
> >> buses of this child bus and then is checked to avoid this unsupported
> >> accesses to every device on these buses.
> > Hi Gilles,
> >
> > Thanks for the patch! I reworked it a little bit to simplify the code
> > in pci_alloc_child_bus(). Can you test it and make sure I didn't
> > break anything?
> >
> Hi Bjorn,
>
> Your rework works as expected. Tested on LS1043A platform with kernel 4.17-rc1, and with some backport on kernel 4.1.35
>
> Suggestion : maybe change the pci_info() string to have :
> pci_bus 0000:xx: extended config space not accessible
> instead of
> pci_bus 0000:xx: extended config space not accessible on secondary bus
> as xx is already the number of the secondary bus
Oops, when I wrote that I was thinking it would be printed for the
bridge device (not the bus). I changed it as you suggest.
Interesting, I didn't think about the fact that pci_info() would work
on a struct pci_bus * as well as on a struct pci_dev *, since it's a
macro and they both have a "dev" member.
> Info : with kernel 4.17-rc1, it turns out I need pcie_aspm=off to
> have the PMC devices behind the PCI-to-PCIe bridge of the PMC safely
> detected/configured. But this is not caused by the patch.
> Without pcie_aspm=off I saw this at one boot :
> "pci 0000:02:0e.0: ASPM: Could not configure common clock" for this bridge, but devices
> correctly detected/configured
> but at most boots I get :
> no ASPM message but "pci 0000:04:02.0: bridge configuration invalid ([bus ff-ff]), reconfiguring "
> instead, and some devices are missing. Also lspci show "rev ff" for some devices.
> I don't see this problem on 4.1.35 with the same backported patch.
This is interesting, especially since you have this unusual topology
of a path to the device that is PCIe, then conventional PCI, then PCIe
again. We *should* be able to use ASPM on the PCIe links, but it's
definitely not a well-tested scenario.
Can you tell if something is actually broken? Sinan's recent change,
04875177dbe0 ("PCI/ASPM: Don't warn if already in common clock mode"),
which appeared in v4.17-rc1, turns off the message in some cases.
The "bridge configuration invalid" message just means the firmware
didn't configure the bridge. We *should* still set it up correctly,
but please report a bug if we don't.
lspci showing "ff" for some devices might be a symptom of the devices
being powered off. In that case config reads normally return ~0 data
(though on your platform maybe it would cause exceptions). I've seen
this in other situations and wondered if it would be worth adding a
hint to lspci so it could say "device may be powered off".
Anyway, if you are seeing something broken (more than just the
messages), please start a new thread about each one. If you do, could
you please:
- open a report at https://bugzilla.kernel.org/, in the Drivers/PCI
component (open a separate bug for each issue you see)
- use kernel version 4.17-rc1 and mark it as a regression if
appropriate
- attach (don't paste inline) the complete dmesg log and "lspci -vv"
output (as root) to the bug
- post a note to linux-pci at vger.kernel.org, cc Fred, Sinan, and me,
and include the link to the bugzilla
Bjorn
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2018-04-20 8:02 Christoph Hellwig
0 siblings, 0 replies; 88+ messages in thread
From: Christoph Hellwig @ 2018-04-20 8:02 UTC (permalink / raw)
To: linux-arm-kernel
To: iommu at lists.linux-foundation.org
Cc: linux-arch at vger.kernel.org
Cc: Michal Simek <monstr@monstr.eu>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-c6x-dev at linux-c6x.org
Cc: linux-hexagon at vger.kernel.org
Cc: linux-m68k at lists.linux-m68k.org
Cc: nios2-dev at lists.rocketboards.org
Cc: openrisc at lists.librecores.org
Cc: linux-parisc at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: linux-kernel at vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.
The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers. The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations. Hopefully we can do some consolidation for them later on
as well.
A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch. Please review them very careful and correct me on
incorrect assumptions.
Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it. It is provided here:
git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2018-04-16 1:22 Andrew Worsley
0 siblings, 0 replies; 88+ messages in thread
From: Andrew Worsley @ 2018-04-16 1:22 UTC (permalink / raw)
To: linux-arm-kernel
This patch clears the remaining i2c buffer overrun problems that I see in my
hardware. When run at 200kHz over 2 days and 17 hours there were *NO* faults seen
despite continously accessing the all the i2c devices. I feel the remaining issues
are related to the TPM not behaving properly at clock speeds of 285kHz or higher.
The other i2c hardware is fine up to maximum 400khz. At these higher clock speeds
the TPM appears to fall behind and I see SDA held low after the TPM read and the
driver report bus arbitration lost errors. Eventually the TPM completely stops
responding and SDA is held low. But accessing the other i2c hardware causes more
i2c clock pulses which lets the SDA go high again then the other i2c devices work
with out problems which further confirms our thinking that the TPM is source of the
remaining i2c problems.
With the additional i2c fixes in the attached patch the Xilinx i2c driver
is working with out problems on our hardware. I recommend you consider adding these
changes which apply on top of the previous fixes that I sent.
Thanks
Andrew Worsley
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2017-11-30 10:25 Mary Cuevas
0 siblings, 0 replies; 88+ messages in thread
From: Mary Cuevas @ 2017-11-30 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Open
Sent from my iPhone
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2017-08-22 1:38 Nicholas Piggin
0 siblings, 0 replies; 88+ messages in thread
From: Nicholas Piggin @ 2017-08-22 1:38 UTC (permalink / raw)
To: linux-arm-kernel
Date: Sun, 20 Aug 2017 13:16:16 +1000
Subject: [PATCH] timers: Fix excessive granularity of new timers after a nohz
idle
When a timer base is idle, it is forwarded when a new timer is added
to ensure that granularity does not become excessive. When not idle,
the timer tick is expected to increment the base.
However there are several problems:
- If an existing timer is modified, the base is forwarded only after
the index is calculated.
- The base is not forwarded by add_timer_on.
- There is a window after a timer is restarted from a nohz ide, after
it is marked not-idle and before the timer tick on this CPU, where a
timer may be added but the ancient base does not get forwarded.
These result in excessive granularity (a 1 jiffy timeout can blow out
to 100s of jiffies), which cause the rcu lockup detector to trigger,
among other things.
Fix this by keeping track of whether the timer base has been idle
since it was last run or forwarded, and if so then forward it before
adding a new timer.
There is still a problem where the mod_timer optimization where it's
modified with the same expiry time can result in excessive granularity
relative to the new shorter interval. That is not addressed by this
patch because checking base->was_idle would increase overhead and it's
a rather special case (you could reason that the caller should not
expect change in absolute expiry time due to such an operation). So
that is noted as a comment.
As well as fixing the visible RCU softlockup failures, I tested an
idle system (with no lockup watchdogs running) and traced all
non-deferrable timer expiries for 1000s, and analysed wakeup latency
relative to requested latency. 1.0 means we slept for as many jiffies
as requested, 2.0 means we slept 2x the time (this suffers jiffies
round-up skew at low absolute times):
max avg std
upstream 506.0 1.20 4.68
patched 2.0 1.08 0.15
This was noticed due to the lockup detector Kconfig changes dropping it
out of people's .configs. When the lockup detectors are enabled, no CPU
can go idle for longer than 4 seconds, which limits the granularity
errors. Sub-optimal timer behaviour is observable on a smaller scale:
max avg std
upstream 9.0 1.05 0.19
patched 2.0 1.04 0.11
Tested-by: David Miller <davem@davemloft.net>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Hi Andrew,
I would have preferred to get comments from the timer maintainers, but
they've been busy or away for the past copule of weeks. Perhaps you
would consider carrying it until then?
Thanks,
Nick
kernel/time/timer.c | 44 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 8f5d1bf18854..dd7be9fe6839 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -203,6 +203,7 @@ struct timer_base {
bool migration_enabled;
bool nohz_active;
bool is_idle;
+ bool was_idle; /* was it idle since last run/fwded */
DECLARE_BITMAP(pending_map, WHEEL_SIZE);
struct hlist_head vectors[WHEEL_SIZE];
} ____cacheline_aligned;
@@ -856,13 +857,19 @@ get_target_base(struct timer_base *base, unsigned tflags)
static inline void forward_timer_base(struct timer_base *base)
{
- unsigned long jnow = READ_ONCE(jiffies);
+ unsigned long jnow;
/*
- * We only forward the base when it's idle and we have a delta between
- * base clock and jiffies.
+ * We only forward the base when we are idle or have just come out
+ * of idle (was_idle logic), and have a delta between base clock
+ * and jiffies. In the common case, run_timers will take care of it.
*/
- if (!base->is_idle || (long) (jnow - base->clk) < 2)
+ if (likely(!base->was_idle))
+ return;
+
+ jnow = READ_ONCE(jiffies);
+ base->was_idle = base->is_idle;
+ if ((long)(jnow - base->clk) < 2)
return;
/*
@@ -938,6 +945,13 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
* same array bucket then just return:
*/
if (timer_pending(timer)) {
+ /*
+ * The downside of this optimization is that it can result in
+ * larger granularity than you would get from adding a new
+ * timer with this expiry. Would a timer flag for networking
+ * be appropriate, then we can try to keep expiry of general
+ * timers within ~1/8th of their interval?
+ */
if (timer->expires == expires)
return 1;
@@ -948,6 +962,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
* dequeue/enqueue dance.
*/
base = lock_timer_base(timer, &flags);
+ forward_timer_base(base);
clk = base->clk;
idx = calc_wheel_index(expires, clk);
@@ -964,6 +979,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
}
} else {
base = lock_timer_base(timer, &flags);
+ forward_timer_base(base);
}
ret = detach_if_pending(timer, base, false);
@@ -991,12 +1007,10 @@ __mod_timer(struct timer_list *timer, unsigned long expires, bool pending_only)
raw_spin_lock(&base->lock);
WRITE_ONCE(timer->flags,
(timer->flags & ~TIMER_BASEMASK) | base->cpu);
+ forward_timer_base(base);
}
}
- /* Try to forward a stale timer base clock */
- forward_timer_base(base);
-
timer->expires = expires;
/*
* If 'idx' was calculated above and the base time did not advance
@@ -1112,6 +1126,7 @@ void add_timer_on(struct timer_list *timer, int cpu)
WRITE_ONCE(timer->flags,
(timer->flags & ~TIMER_BASEMASK) | cpu);
}
+ forward_timer_base(base);
debug_activate(timer, timer->expires);
internal_add_timer(base, timer);
@@ -1499,8 +1514,10 @@ u64 get_next_timer_interrupt(unsigned long basej, u64 basem)
/*
* If we expect to sleep more than a tick, mark the base idle:
*/
- if ((expires - basem) > TICK_NSEC)
+ if ((expires - basem) > TICK_NSEC) {
+ base->was_idle = true;
base->is_idle = true;
+ }
}
raw_spin_unlock(&base->lock);
@@ -1611,6 +1628,17 @@ static __latent_entropy void run_timer_softirq(struct softirq_action *h)
{
struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
+ /*
+ * was_idle must be cleared before running timers so that any timer
+ * functions that call mod_timer will not try to forward the base.
+ *
+ * The deferrable base does not do idle tracking at all, so we do
+ * not forward it. This can result in very large variations in
+ * granularity for deferrable timers, but they can be deferred for
+ * long periods due to idle.
+ */
+ base->was_idle = false;
+
__run_timers(base);
if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && base->nohz_active)
__run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
--
2.13.3
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
2017-06-26 13:16 [PATCH] arm64: use readq() instead of readl() to read 64bit entry_point Luc Van Oostenryck
@ 2017-07-03 23:46 ` Khuong Dinh
0 siblings, 0 replies; 88+ messages in thread
From: Khuong Dinh @ 2017-07-03 23:46 UTC (permalink / raw)
To: linux-arm-kernel
It is good with X-Gene 1/2.
Tested-by: Khuong Dinh <kdinh@apm.com>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2017-06-04 11:59 Yury Norov
0 siblings, 0 replies; 88+ messages in thread
From: Yury Norov @ 2017-06-04 11:59 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
Hi Catalin,
Here is a rebase of latest kernel patchset against next-20170602. There's almost
no changes, but there are some conflicts that are not trivial, and I'd like to
refresh the submission therefore.
How are your experiments with testing and benchmarking of ILP32 are going? In
my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
LMBench shows no difference for LP64 and expected performance boost for ILP32
(compared to LP64 results).
Steve Ellcey is handling upstream submission of Glibc patches. The patches are
ready and have been reviewed and reworked per community?s comments. There are
no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
on ILP32 kernel submission.
Catalin, regarding rootfs, is OpenSuSe?s build sufficient for your experiments?
I?ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
them to Debian.
One last thing I wanted to check with you about is ILP32 PCS - does, in your
view, ARM Ltd. needs to publish any additional docs for ABI to become official?
Below is the regular description.
Thanks.
Yury
--------
This series enables aarch64 with ilp32 mode.
As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t is is used by new userspace). Also it
deprecates getrlimit and setrlimit syscalls prior to prlimit64.
This version is based on linux-next from 2017-03-01. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.
Patches 1, 2, 3 and 8 are general, and may be applied separately.
This is the rebase of v7 - still no major changes has been made.
Kernel and GLIBC trees:
https://github.com/norov/linux/tree/ilp32-20170602
https://github.com/norov/glibc/tree/dev9
(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)
Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
v7: https://lkml.org/lkml/2017/1/9/213
v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
v7: Resend 2:
- vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
- rebased on next-20170602.
Andrew Pinski (6):
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: ensure the kernel is compiled for LP64
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (13):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit ABI: introduce ARCH_32BIT_OFF_T config option
asm-generic: Drop getrlimit and setrlimit syscalls from default list
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Documentation/arm64/ilp32.txt | 45 +++++++
arch/Kconfig | 4 +
arch/arc/Kconfig | 1 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 19 ++-
arch/arm64/Makefile | 8 ++
arch/arm64/include/asm/compat.h | 19 +--
arch/arm64/include/asm/elf.h | 37 ++----
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h | 6 +-
arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/include/asm/processor.h | 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/seccomp.h | 2 +-
arch/arm64/include/asm/signal32.h | 9 +-
arch/arm64/include/asm/signal32_common.h | 27 ++++
arch/arm64/include/asm/signal_common.h | 33 +++++
arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/unistd.h | 13 ++
arch/arm64/kernel/Makefile | 8 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
arch/arm64/kernel/cpufeature.c | 8 +-
arch/arm64/kernel/cpuinfo.c | 20 +--
arch/arm64/kernel/entry.S | 34 +++++-
arch/arm64/kernel/entry32.S | 80 ------------
arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
arch/arm64/kernel/entry_ilp32.S | 22 ++++
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 8 +-
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c | 7 +-
arch/arm64/kernel/ptrace.c | 80 ++++++++++--
arch/arm64/kernel/signal.c | 102 ++++++++++------
arch/arm64/kernel/signal32.c | 107 ----------------
arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
arch/arm64/kernel/traps.c | 5 +-
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
arch/arm64/kernel/vdso.c | 69 +++++++++--
arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
arch/arm64/kernel/vdso/vdso.S | 6 +-
arch/blackfin/Kconfig | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/Kconfig | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/metag/Kconfig | 1 +
arch/metag/include/uapi/asm/unistd.h | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/Kconfig | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/score/include/uapi/asm/unistd.h | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/tile/Kconfig | 1 +
arch/tile/include/uapi/asm/unistd.h | 1 +
arch/tile/kernel/compat.c | 3 +
arch/unicore32/Kconfig | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/um/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 2 +-
include/linux/fcntl.h | 2 +-
include/linux/thread_bits.h | 63 ++++++++++
include/linux/thread_info.h | 66 ++--------
include/uapi/asm-generic/unistd.h | 10 +-
93 files changed, 1601 insertions(+), 413 deletions(-)
create mode 100644 Documentation/arm64/ilp32.txt
create mode 100644 arch/arm64/include/asm/is_compat.h
create mode 100644 arch/arm64/include/asm/signal32_common.h
create mode 100644 arch/arm64/include/asm/signal_common.h
create mode 100644 arch/arm64/include/asm/signal_ilp32.h
create mode 100644 arch/arm64/kernel/binfmt_elf32.c
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
create mode 100644 arch/arm64/kernel/entry32_common.S
create mode 100644 arch/arm64/kernel/entry_ilp32.S
create mode 100644 arch/arm64/kernel/signal32_common.c
create mode 100644 arch/arm64/kernel/signal_ilp32.c
create mode 100644 arch/arm64/kernel/sys_ilp32.c
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
create mode 100644 include/linux/thread_bits.h
--
2.11.0
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
[not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
@ 2017-05-04 16:44 ` gengdongjiu
0 siblings, 0 replies; 88+ messages in thread
From: gengdongjiu @ 2017-05-04 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Dear James,
Thanks a lot for your review and comments. I am very sorry for the
late response.
2017-05-04 23:42 GMT+08:00 gengdongjiu <gengdj.1984@gmail.com>:
> Hi Dongjiu Geng,
>
> On 30/04/17 06:37, Dongjiu Geng wrote:
>> when happen SEA, deliver signal bus and handle the ioctl that
>> inject SEA abort to guest, so that guest can handle the SEA error.
>
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 105b6ab..a96594f 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -20,8 +20,10 @@
>> @@ -1238,6 +1240,36 @@ static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, kvm_pfn_t pfn,
>> __coherent_cache_guest_page(vcpu, pfn, size);
>> }
>>
>> +static void kvm_send_signal(unsigned long address, bool hugetlb, bool hwpoison)
>> +{
>> + siginfo_t info;
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + if (hwpoison)
>> + info.si_code = BUS_MCEERR_AR;
>> + else
>> + info.si_code = 0;
>> +
>> + info.si_addr = (void __user *)address;
>> + if (hugetlb)
>> + info.si_addr_lsb = PMD_SHIFT;
>> + else
>> + info.si_addr_lsb = PAGE_SHIFT;
>> +
>> + send_sig_info(SIGBUS, &info, current);
>> +}
>> +
> ? [hide part of quote]
>
> Punit reviewed the other version of this patch, this PMD_SHIFT is not the right
> thing to do, it needs a more accurate set of calls and shifts as there may be
> hugetlbfs pages other than PMD_SIZE.
>
> https://www.spinics.net/lists/arm-kernel/msg568919.html
>
> I haven't posted a new version of that patch because I was still hunting a bug
> in the hugepage/hwpoison code, even with Punit's fixes series I see -EFAULT
> returned to userspace instead of this hwpoison code being invoked.
Ok, got it, thanks for your information.
>
> Please avoid duplicating functionality between patches, it wastes reviewers
> time, especially when we know there are problems with this approach.
>
>
>> +static void kvm_handle_bad_page(unsigned long address,
>> + bool hugetlb, bool hwpoison)
>> +{
>> + /* handle both hwpoison and other synchronous external Abort */
>> + if (hwpoison)
>> + kvm_send_signal(address, hugetlb, true);
>> + else
>> + kvm_send_signal(address, hugetlb, false);
>> +}
>
> Why the extra level of indirection? We only want to signal userspace like this
> from KVM for hwpoison. Signals for RAS related reasons should come from the bits
> of the kernel that decoded the error.
For the SEA, the are maily two types:
0b010000 Synchronous External Abort on memory access.
0b0101xx Synchronous External Abort on page table walk. DFSC[1:0]
encode the level.
hwpoison should belong to the "Synchronous External Abort on memory access"
if the SEA type is not hwpoison, such as page table walk, do you mean
KVM do not deliver the SIGBUS?
If so, how the KVM handle the SEA type other than hwpoison?
>
> (hwpoison for KVM is a corner case as Qemu's memory effectively has two users,
> Qemu and KVM. This isn't the example of how user-space gets signalled.)
>
>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index b37446a..780e3c4 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -277,6 +277,13 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>> return -EINVAL;
>> }
>>
>> +int kvm_vcpu_ioctl_sea(struct kvm_vcpu *vcpu)
>> +{
>> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
>> +
>> + return 0;
>> +}
>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index bb02909..1d2e2e7 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -1306,6 +1306,7 @@ struct kvm_s390_ucas_mapping {
>> #define KVM_S390_GET_IRQ_STATE _IOW(KVMIO, 0xb6, struct kvm_s390_irq_state)
>> /* Available with KVM_CAP_X86_SMM */
>> #define KVM_SMI _IO(KVMIO, 0xb7)
>> +#define KVM_ARM_SEA _IO(KVMIO, 0xb8)
>>
>> #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
>> #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
>>
>
> Why do we need a userspace API for SEA? It can also be done by using
> KVM_{G,S}ET_ONE_REG to change the vcpu registers. The advantage of doing it this
> way is you can choose which ESR value to use.
>
> Adding a new API call to do something you could do with an old one doesn't look
> right.
James, I considered your suggestion before that use the
KVM_{G,S}ET_ONE_REG to change the vcpu registers. but I found it does
not have difference to use the alread existed KVM API. so may be
changing the vcpu registers in qemu will duplicate with the KVM APIs.
injection a SEA is no more than setting some registers: elr_el1, PC,
PSTATE, SPSR_el1, far_el1, esr_el1
I seen this KVM API do the same thing as Qemu. do you found call this
API will have issue and necessary to choose another ESR value?
I pasted the alread existed KVM API code:
static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned
long addr)
{
unsigned long cpsr = *vcpu_cpsr(vcpu);
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
u32 esr = 0;
*vcpu_elr_el1(vcpu) = *vcpu_pc(vcpu);
*vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
*vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
*vcpu_spsr(vcpu) = cpsr;
vcpu_sys_reg(vcpu, FAR_EL1) = addr;
/*
* Build an {i,d}abort, depending on the level and the
* instruction set. Report an external synchronous abort.
*/
if (kvm_vcpu_trap_il_is32bit(vcpu))
esr |= ESR_ELx_IL;
/*
* Here, the guest runs in AArch64 mode when in EL1. If we get
* an AArch32 fault, it means we managed to trap an EL0 fault.
*/
if (is_aarch32 || (cpsr & PSR_MODE_MASK) == PSR_MODE_EL0t)
esr |= (ESR_ELx_EC_IABT_LOW << ESR_ELx_EC_SHIFT);
else
esr |= (ESR_ELx_EC_IABT_CUR << ESR_ELx_EC_SHIFT);
if (!is_iabt)
esr |= ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT;
vcpu_sys_reg(vcpu, ESR_EL1) = esr | ESR_ELx_FSC_EXTABT;
}
static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt,
unsigned long addr)
{
u32 vect_offset;
u32 *far, *fsr;
bool is_lpae;
if (is_pabt) {
vect_offset = 12;
far = &vcpu_cp15(vcpu, c6_IFAR);
fsr = &vcpu_cp15(vcpu, c5_IFSR);
} else { /* !iabt */
vect_offset = 16;
far = &vcpu_cp15(vcpu, c6_DFAR);
fsr = &vcpu_cp15(vcpu, c5_DFSR);
}
prepare_fault32(vcpu, COMPAT_PSR_MODE_ABT | COMPAT_PSR_A_BIT, vect_offset);
*far = addr;
/* Give the guest an IMPLEMENTATION DEFINED exception */
is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
if (is_lpae)
*fsr = 1 << 9 | 0x34;
else
*fsr = 0x14;
}
/**
* kvm_inject_dabt - inject a data abort into the guest
* @vcpu: The VCPU to receive the undefined exception
* @addr: The address to report in the DFAR
*
* It is assumed that this code is called from the VCPU thread and that the
* VCPU therefore is not currently executing guest code.
*/
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
{
if (!(vcpu->arch.hcr_el2 & HCR_RW))
inject_abt32(vcpu, false, addr);
else
inject_abt64(vcpu, false, addr);
}
>
>
> Thanks,
>
> James
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2017-01-31 7:58 Andy Gross
0 siblings, 0 replies; 88+ messages in thread
From: Andy Gross @ 2017-01-31 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [Patch v5 0/2] Support ARM SMCC SoC vendor quirks
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms. When this occurs, the
call must be restarted using information that was passed back during
the original smc call.
The first patch in this series adds a quirk structure and also adds a
quirk parameter to arm_smccc_smc calls. I added macros to allow users
to choose the API they need. This keeps all of the current users who
do not need quirks from having to change anything.
The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.
The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7
Changes from v4:
- Fix issue with hvc calls.
Changes from v3:
- Fix documentation
Changes from v2:
- Use variadic macros
Changes from v1:
- Add macros to handle both use cases per review comments
Andy Gross (2):
arm: kernel: Add SMC structure parameter
firmware: qcom: scm: Fix interrupted SCM calls
arch/arm/kernel/armksyms.c | 2 +-
arch/arm/kernel/smccc-call.S | 7 ++++---
arch/arm64/kernel/arm64ksyms.c | 2 +-
arch/arm64/kernel/asm-offsets.c | 7 +++++--
arch/arm64/kernel/smccc-call.S | 22 ++++++++++++++++------
drivers/firmware/qcom_scm-64.c | 13 ++++++++++---
include/linux/arm-smccc.h | 38 +++++++++++++++++++++++++++++++-------
7 files changed, 68 insertions(+), 23 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-12-01 10:00 Ramana Radhakrishnan
0 siblings, 0 replies; 88+ messages in thread
From: Ramana Radhakrishnan @ 2016-12-01 10:00 UTC (permalink / raw)
To: linux-arm-kernel
>
> By the way, how is this implemented? Some of them overlap existing
> callee-saved registers.
The AArch64 PCS requires that only the bottom 64 bits of SIMD
registers (v8-v15) are callee-saved. The top 64 bits of the current
Advanced SIMD registers are the responsibility of the caller. This
naturally extends to SVE.
Ramana
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-11-11 3:38 Chunyan Zhang
0 siblings, 0 replies; 88+ messages in thread
From: Chunyan Zhang @ 2016-11-11 3:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Steven,
On 21 October 2016 at 20:13, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 18 Oct 2016 16:08:58 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>
>> This is getting better, but I still have some nits.
>>
>
> Thanks.
>
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>> include/linux/trace.h | 28 +++++++++++
>>> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 159 insertions(+), 1 deletion(-)
>>> create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..eb1c5b8
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next - pointer to the next trace_export
>>> + * write - copy traces which have been delt with ->commit() to
>>> + * the destination
>>> + */
>>> +struct trace_export {
>>> + struct trace_export __rcu *next;
>>> + void (*write)(const char *, unsigned int);
>>
>> Why const char*? Why not const void *? This will never be a string.
>>
>
> Will revise this.
>
>>
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif /* CONFIG_TRACING */
>>> +
>>> +#endif /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..db94ec1 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/poll.h>
>>> #include <linux/nmi.h>
>>> #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>> #include <linux/sched/rt.h>
>>>
>>> #include "trace.h"
>>> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>> ftrace_trace_userstack(buffer, flags, pc);
>>> }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> + struct ring_buffer_event *event)
>>> +{
>>> + struct trace_entry *entry;
>>> + unsigned int size = 0;
>>> +
>>> + entry = ring_buffer_event_data(event);
>>> +
>>> + size = ring_buffer_event_length(event);
>>> +
>>> + if (export->write)
>>> + export->write((char *)entry, size);
>>
>> Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
>>
>> And if there is, this can be racy. As in
>>
>>
>> CPU 0: CPU 1:
>> ------ ------
>> if (export->write)
>>
>> export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
Any further comments? :)
Thanks,
Chunyan
>
> Thanks for the review,
> Chunyan
>
>>
>> export->write(entry, size);
>>
>> BOOM!
>>
>>
>> -- Steve
>>
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> + static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> + static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>> +{
>>> + struct trace_export *export;
>>> +
>>> + preempt_disable_notrace();
>>> +
>>> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> + while (export) {
>>> + trace_process_export(export, event);
>>> + export = rcu_dereference_raw_notrace(export->next);
>>> + }
>>> +
>>> + preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + rcu_assign_pointer(export->next, *list);
>>> + /*
>>> + * We are entering export into the list but another
>>> + * CPU might be walking that list. We need to make sure
>>> + * the export->next pointer is valid before another CPU sees
>>> + * the export pointer included into the list.
>>> + */
>>> + rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + struct trace_export **p;
>>> +
>>> + for (p = list; *p != NULL; p = &(*p)->next)
>>> + if (*p == export)
>>> + break;
>>> +
>>> + if (*p != export)
>>> + return -1;
>>> +
>>> + rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + if (*list == NULL)
>>> + ftrace_exports_enable();
>>> +
>>> + add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + ret = rm_trace_export(list, export);
>>> + if (*list == NULL)
>>> + ftrace_exports_disable();
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> + if (WARN_ON_ONCE(!export->write))
>>> + return -1;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>> void
>>> trace_function(struct trace_array *tr,
>>> unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2273,11 @@ trace_function(struct trace_array *tr,
>>> entry->ip = ip;
>>> entry->parent_ip = parent_ip;
>>>
>>> - if (!call_filter_check_discard(call, entry, buffer, event))
>>> + if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> + if (static_branch_unlikely(&ftrace_exports_enabled))
>>> + ftrace_exports(event);
>>> __buffer_unlock_commit(buffer, event);
>>> + }
>>> }
>>>
>>> #ifdef CONFIG_STACKTRACE
>>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-09-30 14:37 Maxime Ripard
0 siblings, 0 replies; 88+ messages in thread
From: Maxime Ripard @ 2016-09-30 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.
This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.
Let me know what you think,
Maxime
Changes from v4:
- Removed unused functions
Changes from v3:
- Depends on OF in Kconfig
- Fixed typos in the driver comments
- Removed the mention of a "passive" bridge in the bindings doc
- Made the strcuture const
- Removed the nops and best_encoders implementations
- Removed the call to drm_bridge_enable in the sun4i driver
Changes from v2:
- Changed the compatible as suggested
- Rebased on top 4.8
Changes from v1:
- Switch to using a vga-connector
- Use drm_encoder bridge pointer instead of doing our own
- Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
- Switch to of_i2c_get_adapter by node, and put the reference when done
- Rebased on linux-next
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 -
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
--
2.9.3
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-07-10 9:24 Neil Armstrong
0 siblings, 0 replies; 88+ messages in thread
From: Neil Armstrong @ 2016-07-10 9:24 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller
Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.
Currently Meson8b and GXBB SoCs are supported.
Changes since v1 at http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstrong at baylibre.com :
- fix meson8b dtsi
Neil Armstrong (4):
pwm: Add support for Meson PWM Controller
dt-bindings: pwm: Add bindings for Meson PWM Controller
ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
ARM: dts: meson8b: Add Meson8b PWM Controller nodes
.../devicetree/bindings/pwm/pwm-meson.txt | 21 +
arch/arm/boot/dts/meson8b.dtsi | 21 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 ++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-meson.c | 491 +++++++++++++++++++++
6 files changed, 571 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
create mode 100644 drivers/pwm/pwm-meson.c
--
2.7.0
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
2016-04-22 8:25 Daniel Lezcano
@ 2016-04-22 8:27 ` Daniel Lezcano
0 siblings, 0 replies; 88+ messages in thread
From: Daniel Lezcano @ 2016-04-22 8:27 UTC (permalink / raw)
To: linux-arm-kernel
On 04/22/2016 10:25 AM, Daniel Lezcano wrote:
> Hi Rafael,
>
> please pull the following changes for 4.7.
>
> * Constify the cpuidle_ops structure and the types returned by the
> * functions using it (Jisheng Zhang)
Please ignore this email. I did a wrong manipulation with mutt.
Sorry for the noise.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-04-22 8:25 Daniel Lezcano
2016-04-22 8:27 ` Daniel Lezcano
0 siblings, 1 reply; 88+ messages in thread
From: Daniel Lezcano @ 2016-04-22 8:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
please pull the following changes for 4.7.
* Constify the cpuidle_ops structure and the types returned by the
* functions using it (Jisheng Zhang)
Thanks !
-- Daniel
The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:
Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)
are available in the git repository at:
http://git.linaro.org/people/daniel.lezcano/linux.git cpuidle/4.7
for you to fetch changes up to 5e7c17df795e462c70a43f1b3b670e08efefe8fd:
drivers: firmware: psci: use const and __initconst for psci_cpuidle_ops
(2016-04-20 10:44:32 +0200)
----------------------------------------------------------------
Jisheng Zhang (4):
ARM: cpuidle: add const qualifier to cpuidle_ops member in structures
ARM: cpuidle: constify return value of arm_cpuidle_get_ops()
soc: qcom: spm: Use const and __initconst for qcom_cpuidle_ops
drivers: firmware: psci: use const and __initconst for
psci_cpuidle_ops
arch/arm/include/asm/cpuidle.h | 2 +-
arch/arm/kernel/cpuidle.c | 6 +++---
drivers/firmware/psci.c | 2 +-
drivers/soc/qcom/spm.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2016-04-11 7:51 Paul Walmsley
0 siblings, 0 replies; 88+ messages in thread
From: Paul Walmsley @ 2016-04-11 7:51 UTC (permalink / raw)
To: linux-arm-kernel
OMAP baseline test results for v4.6-rc3
Here are some basic OMAP test results for Linux v4.6-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v4.6-rc3/20160411005353/
Test summary
------------
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only
Build: uImage+dtb:
Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
omap2plus_defconfig/omap4-panda,
omap2plus_defconfig/omap4-panda-es,
omap2plus_defconfig/omap4-var-stk-om44,
omap2plus_defconfig/omap3-evm-37xx,
omap2plus_defconfig_n800_only_a/omap2420-n800,
omap2plus_defconfig/omap2430-sdp,
omap2plus_defconfig/am3517-evm,
omap2plus_defconfig/omap3-beagle,
omap2plus_defconfig/omap3-beagle-xm,
omap2plus_defconfig/omap3-sbc-t3517,
omap2plus_defconfig/omap5-uevm,
omap2plus_defconfig/omap5-sbc-t54
Build: zImage:
Pass (18/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
omap2plus_defconfig_omap5_only,
omap2plus_defconfig_dra7xx_only,
omap2plus_defconfig_am43xx_only,
omap2plus_defconfig_ti81xx_only,
rmk_omap3430_ldp_oldconfig,
rmk_omap3430_ldp_allnoconfig,
rmk_omap4430_sdp_oldconfig,
rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig
Build warnings from toolchain: uImage:
(none)
Build warnings from toolchain: uImage+dtb:
(none)
Build warnings from toolchain: zImage:
FAIL (16/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
omap2plus_defconfig_n800_only_a,
omap2plus_defconfig_n800_multi_omap2xxx,
omap2plus_defconfig_2430sdp_only,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
omap2plus_defconfig_omap5_only,
omap2plus_defconfig_dra7xx_only,
omap2plus_defconfig_am43xx_only,
omap2plus_defconfig_ti81xx_only,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_oldconfig, multi_v7_defconfig
Boot to userspace:
FAIL ( 1/18): 2430sdp
skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
3530es31beagle, 3730beaglexm, 3730es12beaglexm,
cmt3517, 5430es2uevm, 2420n800
Kernel warnings during boot to userspace:
FAIL ( 2/18): 4430es2panda, cmt3517
PM: chip retention via suspend:
FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
2430sdp, 5430es2uevm
Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle,
3730beaglexm, 3730es12beaglexm
PM: chip retention via dynamic idle:
FAIL ( 8/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
3530es3beagle, 3530es31beagle, 2430sdp, 5430es2uevm
Pass ( 3/11): 4460pandaes, 3730beaglexm, 3730es12beaglexm
PM: chip off (except CORE, due to errata) via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off (except CORE, due to errata) via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 2/ 4): 37xxevm, 3530es3beagle
Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
Pass ( 1/ 4): 3730es12beaglexm
Kernel warnings during PM test:
FAIL ( 1/18): 4430es2panda
Obsolete Kconfig symbols:
FAIL ( 3/21): omap1_defconfig, omap2plus_defconfig,
multi_v7_defconfig
vmlinux object size
(delta in bytes from test_v4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9)):
text data bss total kernel
+772 -896 0 -124 omap1_defconfig
+772 -920 0 -148 omap1_defconfig_1510innovator_only
+596 -928 0 -332 omap1_defconfig_5912osk_only
-108 +64 0 -44 multi_v7_defconfig
+236 0 0 +236 omap2plus_defconfig
+976 0 0 +976 omap2plus_defconfig_2430sdp_only
+300 0 0 +300 omap2plus_defconfig_am33xx_only
+300 0 0 +300 omap2plus_defconfig_am43xx_only
+236 0 0 +236 omap2plus_defconfig_cpupm
+236 0 0 +236 omap2plus_defconfig_dra7xx_only
+388 -8 0 +380 omap2plus_defconfig_n800_multi_omap2xxx
+420 0 0 +420 omap2plus_defconfig_n800_only_a
+164 0 0 +164 omap2plus_defconfig_no_pm
+172 0 0 +172 omap2plus_defconfig_omap2_4_only
+236 0 0 +236 omap2plus_defconfig_omap3_4_only
+300 0 0 +300 omap2plus_defconfig_omap5_only
+1004 0 0 +1004 omap2plus_defconfig_ti81xx_only
+244 0 -48 +196 rmk_omap3430_ldp_allnoconfig
+3896 0 0 +3896 rmk_omap3430_ldp_oldconfig
+228 0 -48 +180 rmk_omap4430_sdp_allnoconfig
+200 0 0 +200 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9))
avail rsrvd high freed board kconfig
(no differences)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-12-13 21:57 何旦洁
0 siblings, 0 replies; 88+ messages in thread
From: 何旦洁 @ 2015-12-13 21:57 UTC (permalink / raw)
To: linux-arm-kernel
???? iPhone
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-10-27 0:44 xuyiping
0 siblings, 0 replies; 88+ messages in thread
From: xuyiping @ 2015-10-27 0:44 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
[not found] <E1ZqY3A-0004Mt-KH@feisty.vs19.net>
@ 2015-10-26 3:21 ` Jiada Wang
0 siblings, 0 replies; 88+ messages in thread
From: Jiada Wang @ 2015-10-26 3:21 UTC (permalink / raw)
To: linux-arm-kernel
Hello
> Subject: [PATCH v2 4/8] spi: imx: add selection for iMX53 and iMX6
controller type
>
> ECSPI contorller for iMX53 and iMX6 has few hardware issues in slave
> mode and (32*n+1) SPI word size handling comparing to iMX51.
> The change add possibility to detect the SPI controller is use and apply
> workarounds/limitations.
> Documentation for device tree bindings updated
>
> Signed-off-by: Anton Bondarenko <anton_bondarenko@mentor.com>
> ---
> .../devicetree/bindings/spi/fsl-imx-cspi.txt | 2 ++
> drivers/spi/spi-imx.c | 36 ++++++++++++++++++++--
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> index 523341a..425485f 100644
> --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> @@ -9,6 +9,8 @@ Required properties:
> - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
> - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
> - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
> + - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53
> + - "fsl,imx6q-ecspi" for SPI compatible with the one integrated on i.MX6 family
> - reg : Offset and length of the register set for the device
> - interrupts : Should contain CSPI/eCSPI interrupt
> - fsl,spi-num-chipselects : Contains the number of the chipselect
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index d9b730d..41c9cef 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -72,7 +72,8 @@ enum spi_imx_devtype {
> IMX27_CSPI,
> IMX31_CSPI,
> IMX35_CSPI, /* CSPI on all i.mx except above */
> - IMX51_ECSPI, /* ECSPI on i.mx51 and later */
> + IMX51_ECSPI, /* ECSPI on i.mx51 */
> + IMX53_ECSPI, /* ECSPI on i.mx53 and later */
> };
>
> struct spi_imx_data;
> @@ -129,9 +130,20 @@ static inline int is_imx35_cspi(struct spi_imx_data *d)
> return d->devtype_data->devtype == IMX35_CSPI;
> }
>
> +static inline int is_imx53_ecspi(struct spi_imx_data *d)
> +{
> + return d->devtype_data->devtype == IMX53_ECSPI;
> +}
> +
> +static inline int is_imx5x_ecspi(struct spi_imx_data *d)
> +{
> + return d->devtype_data->devtype == IMX51_ECSPI ||
> + d->devtype_data->devtype == IMX53_ECSPI;
> +}
> +
> static inline unsigned spi_imx_get_fifosize(struct spi_imx_data *d)
> {
> - return (d->devtype_data->devtype == IMX51_ECSPI) ? 64 : 8;
> + return is_imx5x_ecspi(d) ? 64 : 8;
> }
>
> #define MXC_SPI_BUF_RX(type) \
> @@ -680,6 +692,16 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data = {
> .devtype = IMX51_ECSPI,
> };
>
> +static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
> + /* i.mx53 and later ecspi shares the functions with i.mx51 one */
> + .intctrl = mx51_ecspi_intctrl,
> + .config = mx51_ecspi_config,
> + .trigger = mx51_ecspi_trigger,
> + .rx_available = mx51_ecspi_rx_available,
> + .reset = mx51_ecspi_reset,
> + .devtype = IMX53_ECSPI,
> +};
> +
> static const struct platform_device_id spi_imx_devtype[] = {
> {
> .name = "imx1-cspi",
> @@ -697,6 +719,12 @@ static const struct platform_device_id spi_imx_devtype[] = {
> .name = "imx35-cspi",
> .driver_data = (kernel_ulong_t) &imx35_cspi_devtype_data,
> }, {
> + .name = "imx53-ecspi",
> + .driver_data = (kernel_ulong_t)&imx53_ecspi_devtype_data,
> + }, {
> + .name = "imx6q-ecspi",
> + .driver_data = (kernel_ulong_t)&imx53_ecspi_devtype_data,
> + }, {
> .name = "imx51-ecspi",
> .driver_data = (kernel_ulong_t) &imx51_ecspi_devtype_data,
> }, {
> @@ -710,6 +738,8 @@ static const struct of_device_id spi_imx_dt_ids[] = {
> { .compatible = "fsl,imx27-cspi", .data = &imx27_cspi_devtype_data, },
> { .compatible = "fsl,imx31-cspi", .data = &imx31_cspi_devtype_data, },
> { .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
> + { .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
> + { .compatible = "fsl,imx6q-ecspi", .data = &imx53_ecspi_devtype_data, },
> { .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
> { /* sentinel */ }
> };
> @@ -1299,7 +1329,7 @@ static int spi_imx_probe(struct platform_device *pdev)
> * Only validated on i.mx6 now, can remove the constrain if validated on
> * other chips.
> */
> - if (spi_imx->devtype_data == &imx51_ecspi_devtype_data &&
> + if (is_imx5x_ecspi(spi_imx) &&
> spi_imx_sdma_init(&pdev->dev, spi_imx, master))
> dev_err(&pdev->dev, "dma setup error,use pio instead\n");
>
>
With this patch, there will still be issues with SPI controller on imx6
soc other than imx6q,
for example SPI controller on imx6sl has compatibility
"compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi";"
So I would suggest to update device-tree file,
for example
imx53.dtsi
"fsl,imx53-ecspi", "fsl,imx51-ecspi"; -> "fsl,imx53-ecspi";
imx6qdl.dtsi
compatible = "fsl,imx6q-ecspi", "fsl,imx51-ecspi"; -> compatible =
"fsl,imx6q-ecspi", "fsl,imx53-ecspi";
imx6sl.dtsi
compatible = "fsl,imx6sl-ecspi", "fsl,imx51-ecspi"; -> compatible =
"fsl,imx6sl-ecspi", "fsl,imx53-ecspi";
etc...
by doing this, then only compatible string "fsl,imx53-ecspi" need to be
added in driver code.
Thanks,
Jiada
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
2015-09-01 14:14 Mika Penttilä
@ 2015-09-01 15:22 ` Fabio Estevam
0 siblings, 0 replies; 88+ messages in thread
From: Fabio Estevam @ 2015-09-01 15:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 1, 2015 at 11:14 AM, Mika Penttil?
<mika.j.penttila@gmail.com> wrote:
> This one causes imx6q with debug uart connected to "schedule while
> atomic" endlessly :
Yes, I have sent a revert patch for it:
http://www.spinics.net/lists/arm-kernel/msg439995.html
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
0 siblings, 1 reply; 88+ messages in thread
From: Mika Penttilä @ 2015-09-01 14:14 UTC (permalink / raw)
To: linux-arm-kernel
This one causes imx6q with debug uart connected to "schedule while
atomic" endlessly :
9e7b399d6528eac33a6fbfceb2b92af209c3454d is the first bad commit
commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d
Author: Eduardo Valentin <edubezval@gmail.com>
Date: Tue Aug 11 10:21:20 2015 -0700
serial: imx: remove unbalanced clk_prepare
The current code attempts to prepare clk_per and clk_ipg
before using the device. However, the result is an extra
prepare call on each clock. Here is the output of uart
clocks (only uart enabled and used as console):
$ grep uart /sys/kernel/debug/clk/clk_summary
uart_serial 1 2 80000000 0 0
uart 1 2 66000000 0 0
This patch balances the calls of prepares. The result is:
$ grep uart /sys/kernel/debug/clk/clk_summary
uart_serial 1 1 80000000 0 0
uart 1 1 66000000 0 0
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial at vger.kernel.org
Cc: linux-pm at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-07-22 14:05 Chunfeng Yun
0 siblings, 0 replies; 88+ messages in thread
From: Chunfeng Yun @ 2015-07-22 14:05 UTC (permalink / raw)
To: linux-arm-kernel
>From ac1e8724bfa47494223bad0af450c1a63cd2fe0c Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Wed, 22 Jul 2015 21:15:15 +0800
Subject: [PATCH 0/5] *** SUBJECT HERE ***
The patch supports MediaTek's xHCI controller.
There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.
2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.
3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.
A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.
Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue
Chunfeng Yun (5):
dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
dt-bindings: Add a binding for Mediatek xHCI host controller
usb: phy: add usb3.0 phy driver for mt65xx SoCs
xhci: mediatek: support MTK xHCI host controller
arm64: dts: mediatek: add xHCI & usb phy for mt8173
.../devicetree/bindings/phy/phy-mt65xx-u3.txt | 21 +
.../devicetree/bindings/usb/mt8173-xhci.txt | 50 ++
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 31 +
drivers/phy/Kconfig | 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-mt65xx-usb3.c | 426 +++++++++++
drivers/usb/host/Kconfig | 9 +
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-mtk-sch.c | 436 +++++++++++
drivers/usb/host/xhci-mtk.c | 836 +++++++++++++++++++++
drivers/usb/host/xhci-mtk.h | 135 ++++
drivers/usb/host/xhci-ring.c | 35 +-
drivers/usb/host/xhci.c | 19 +-
drivers/usb/host/xhci.h | 1 +
15 files changed, 2021 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-u3.txt
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
create mode 100644 drivers/phy/phy-mt65xx-usb3.c
create mode 100644 drivers/usb/host/xhci-mtk-sch.c
create mode 100644 drivers/usb/host/xhci-mtk.c
create mode 100644 drivers/usb/host/xhci-mtk.h
--
1.8.1.1.dirty
In-Reply-To:
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-07-15 9:32 Yuan Yao
0 siblings, 0 replies; 88+ messages in thread
From: Yuan Yao @ 2015-07-15 9:32 UTC (permalink / raw)
To: linux-arm-kernel
This patch has been tested on Fresscale LS-1 SOCs.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-05-18 20:00 raghu MG
0 siblings, 0 replies; 88+ messages in thread
From: raghu MG @ 2015-05-18 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This mail is regarding Linux smp boot on ARMADA-XP MV2860
.
CPU-1 doesnt boot/go through the boot sequence & it fails to come
online & dumps this message
CPU1:failed to come online .
The CPU-1 boot register is programmed with physical address of
-->armada_xp_secondary_startup function & then cpu-0 deasserts the CPU-1.
I am using armada-xp-gp.dts with armada-xp-mv78260.dts included in it.
Any help would be appreciated.
Regards
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-04-21 10:18 Ard Biesheuvel
0 siblings, 0 replies; 88+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 12:13, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> This updates the PROCINFO offset-to-setup-function fields of the
>> Thumb2 capable CPU definitions to include the Thumb bit when building
>> a Thumb2 kernel. This ensures that these function are always called
>> in the correct mode.
>
> I don't think this is necessary, in fact, I think this is positively
> regression causing.
>
> The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> As we have seen already from the kernel dumps from the V7M kernel, when
> it calculates initfunc - name in a T2 kernel, the resulting value is an
> _odd_ number.
>
OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
But looking at proc-v7.S again, the problem may just be the missing
ENDPROC() declarations for a couple of the setup() functions, which
explains why they are lacking the Thumb annotations.
> Using BSYM() here will increment it to be the next _even_ number, which
> is wrong as this will potentially point at either half way through a
> 32-bit T2 instruction, or the second 16-bit T2 instruction.
>
Agreed.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-02-26 16:56 Jorge Ramirez-Ortiz
0 siblings, 0 replies; 88+ messages in thread
From: Jorge Ramirez-Ortiz @ 2015-02-26 16:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Subject: [PATCH v5] drivers/tty: amba: defer probing DMA availability until hw_init
In-Reply-To: [PATCH v4] drivers/tty: amba: defer probing DMA availability until hw_init
checkpatch.pl didn't catch 'struct device * const uap_dev'
resending
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2015-02-18 16:14 Lee Jones
0 siblings, 0 replies; 88+ messages in thread
From: Lee Jones @ 2015-02-18 16:14 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH v2 0/4] clk: st: New clock domain
v1 => v2:
- Turned the ST specific driver into a generic one
Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die. The only way to recover from this failure is to
restart.
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.
Lee Jones (4):
ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
ARM: sti: stih407-family: Provide Clock Domain information
clk: Provide an always-on clock domain framework
clk: dt: Introduce always-on clock domain documentation
.../devicetree/bindings/clock/clk-domain.txt | 35 ++++++++++++
arch/arm/boot/dts/stih407-family.dtsi | 13 +++++
drivers/clk/Makefile | 1 +
drivers/clk/clkdomain.c | 63 ++++++++++++++++++++++
include/dt-bindings/clock/stih407-clks.h | 4 ++
5 files changed, 116 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
create mode 100644 drivers/clk/clkdomain.c
--
1.9.1
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-10-28 14:13 Mark Rutland
0 siblings, 0 replies; 88+ messages in thread
From: Mark Rutland @ 2014-10-28 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Bcc:
Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
Reply-To:
In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> Add page protections for arm64 similar to those in arm.
> This is for security reasons to prevent certain classes
> of exploits. The current method:
>
> - Map all memory as either RWX or RW. We round to the nearest
> section to avoid creating page tables before everything is mapped
> - Once everything is mapped, if either end of the RWX section should
> not be X, we split the PMD and remap as necessary
> - When initmem is to be freed, we change the permissions back to
> RW (using stop machine if necessary to flush the TLB)
> - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> read only.
>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> v4: Combined the Kconfig options
> ---
> arch/arm64/Kconfig.debug | 23 +++
> arch/arm64/include/asm/cacheflush.h | 4 +
> arch/arm64/kernel/vmlinux.lds.S | 17 ++
> arch/arm64/mm/init.c | 1 +
> arch/arm64/mm/mm.h | 2 +
> arch/arm64/mm/mmu.c | 303 +++++++++++++++++++++++++++++++-----
> 6 files changed, 314 insertions(+), 36 deletions(-)
With this patch applied to v3.18-rc2, my board to blows up at boot when
using UEFI (without DEBUG_RODATA selected):
---->8----
EFI stub: Booting Linux Kernel...
Initializing cgroup subsys cpu
Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
CPU: AArch64 Processor [410fd030] revision 0
Detected VIPT I-cache on CPU0
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.40 by ARM Juno EFI Oct 7 2014 15:05:42
efi: ACPI=0xfebdc000 ACPI 2.0=0xfebdc014
cma: Reserved 16 MiB at fd800000
BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
Call trace:
[<ffffffc000087ec8>] dump_backtrace+0x0/0x124
[<ffffffc000087ffc>] show_stack+0x10/0x1c
[<ffffffc0004ebd58>] dump_stack+0x74/0xb8
[<ffffffc0004eb018>] panic+0xe0/0x220
[<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
[<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
[<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
[<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
[<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
[<ffffffc0006978a8>] setup_arch+0x408/0x5c0
[<ffffffc00069566c>] start_kernel+0x94/0x3a0
---[ end Kernel panic - not syncing: BUG!
---->8----
I've not yet figured out precisely why. I haven't tried a !EFI boot
because of the way my board is set up at the moment.
Mark.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-09-22 19:41 Santosh Shilimkar
0 siblings, 0 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2014-09-22 19:41 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [GIT PULL] ARM: dts: Keystone DTS updates for 3.18
Hi Arm-soc folks,
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-dts
for you to fetch changes up to b2ed7d98e1c7098f452cf95ab69211a2f8e02ac8:
ARM: dts: keystone: fix bindings for pcie and usb clock nodes (2014-09-22 15:19:36 -0400)
----------------------------------------------------------------
Keystone DTS updates for v3.18
- Add IRQ and GPIO nodes
- Fix SPI chip select
- Fix usb and pcie clock nodes
----------------------------------------------------------------
Grygorii Strashko (2):
ARM: dts: keystone: add keystone irq controller node
ARM: dts: keystone: add dsp gpio controllers nodes
Karicheri Muralidharan (1):
ARM: dts: keystone: k2l: Fix chip selects for SPI devices
Karicheri, Muralidharan (1):
ARM: dts: keystone: fix bindings for pcie and usb clock nodes
arch/arm/boot/dts/k2e-clocks.dtsi | 6 ++--
arch/arm/boot/dts/k2e.dtsi | 7 +++++
arch/arm/boot/dts/k2hk.dtsi | 56 +++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/k2l.dtsi | 42 ++++++++++++++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 8 ++++++
5 files changed, 116 insertions(+), 3 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-09-22 7:45 Jingchang Lu
0 siblings, 0 replies; 88+ messages in thread
From: Jingchang Lu @ 2014-09-22 7:45 UTC (permalink / raw)
To: linux-arm-kernel
This series contain the support for Freescale LS1021A CPU and LS1021A-QDS
and LS1021A-TWR board.
The LS1021A SoC combines two ARM Cortex-A7 cores that have been optimized
for high reliability and pack the highest level of integration available
for sub-3W embedded communications processors and with a comprehensive
enablement model focused on ease of programmability.
The LS1021A SoC shares IPs with i.MX family, Vybrid family and Freescale
PowerPC platform.
For the detail information about LS1021A SoC, please refer to the RM doc.
---
changes in v4:
add "syscon" compatible to device tree scfg and dcfg node, and
remove uncompleted dcsr related node.
remove mxc_restart reference in DT_MACHINE_START.
remove dma_zone_size defination in DT_MACHINE_START.
changes in v3:
rewrite scfg and dcfg binding doc description.
remove sai related node leaving to the driver support.
changes in v2:
remove unused nodes.
wakeup the secondary core by IPI call to u-boot standby procedure.
add dt-bindings for LS1021A SoC and platform gerenal configuration nodes.
----------------------------------------------------------------
Jingchang Lu (6):
ARM: dts: Add SoC level device tree support for LS1021A
ARM: dts: Add initial LS1021A QDS board dts support
ARM: dts: Add initial LS1021A TWR board dts support
dt-bindings: arm: add Freescale LS1021A SoC device tree binding
ARM: imx: Add initial support for Freescale LS1021A
ARM: imx: Add Freescale LS1021A SMP support
Documentation/devicetree/bindings/arm/fsl.txt | 38 ++++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/ls1021a-qds.dts | 285 ++++++++++++++++++++++++++
arch/arm/boot/dts/ls1021a-twr.dts | 117 +++++++++++
arch/arm/boot/dts/ls1021a.dtsi | 539 ++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-imx/Kconfig | 14 ++
arch/arm/mach-imx/Makefile | 4 +-
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/mach-ls1021a.c | 22 +++
arch/arm/mach-imx/platsmp.c | 32 +++
10 files changed, 1053 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts
create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts
create mode 100644 arch/arm/boot/dts/ls1021a.dtsi
create mode 100644 arch/arm/mach-imx/mach-ls1021a.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-07-09 17:49 Sebastian Andrzej Siewior
0 siblings, 0 replies; 88+ messages in thread
From: Sebastian Andrzej Siewior @ 2014-07-09 17:49 UTC (permalink / raw)
To: linux-arm-kernel
This is version three of the patch set. Unless something serious comes up
I would drop the RFC on the next post.
So far I should have everything covered up comparing to the omap-serial
driver except for the throttle callbacks. And now I would slowly start
looking into DMA support?
Sebastian
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-05-24 1:21 Loc Ho
0 siblings, 0 replies; 88+ messages in thread
From: Loc Ho @ 2014-05-24 1:21 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for the APM X-Gene SoC EDAC driver.
v2:
* Add EDAC entry in MAINTAINERS for APM EDAC driver
* Remove the MC scrub patch
* Remove the word 'Caches' from Kconfig
* Change all MASK defines to use BIT(x)
* Update comment or remove them
* Wrap error injection code around CONFIG_EDAC_DEBUG
* Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl
* Change all function XXX_hw_init to XXX_hw_ctl
* Fix typo 'activie'
* Move calling function edac_mc_alloc after resource retrieval
* Check for NULL on platform_get_resource return if reference directly
* Add documentation for struct xgene_edac_pmd_ctx
* Move L1 and L2 check out of function xgene_edac_pmd_check to its own
functions
* Use for loop for configure each CPU of an PMD
* Replace /2 by >> 1
* Remove unnecessary comment on edac_device_add_device failure
* Make mem_err_ip static const
* Unwind EDAC register correctly if failed
---
Loc Ho (4):
MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
Documentation: Add documentation for the APM X-Gene SoC EDAC DTS
binding
edac: Add APM X-Gene SoC EDAC driver
arm64: Add APM X-Gene SoC EDAC DTS entries
.../devicetree/bindings/edac/apm-xgene-edac.txt | 70 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/apm-storm.dtsi | 89 +
drivers/edac/Kconfig | 9 +-
drivers/edac/Makefile | 3 +
drivers/edac/xgene_edac.c | 1993 ++++++++++++++++++++
6 files changed, 2171 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
create mode 100644 drivers/edac/xgene_edac.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-05-12 16:40 Santosh Shilimkar
0 siblings, 0 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2014-05-12 16:40 UTC (permalink / raw)
To: linux-arm-kernel
>From 14f3791439b5a6cf12127fb80204265533d92664 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 12 May 2014 12:28:23 -0400
Subject: [GIT PULL 1/2] ARM: Keystone SOC updates for 3.16
Hi Arm-soc folks,
Please pull below keystone SOC updates for 3.16. It merges cleanly with
arm-soc 'next/soc' head. As already discussed, the $subject pull request
has a depedency with DT dma-properties pull request [1] I sent last week
to be pulled into arm-soc.
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-soc
for you to fetch changes up to 14f3791439b5a6cf12127fb80204265533d92664:
ARM: keystone: Update the dma offset for non-dt platform devices (2014-05-08 15:43:33 -0400)
----------------------------------------------------------------
Keystone SOC updates for 3.16
- Drop unused COMMON_CLK_DEBUG option
- Enable MTD_SPI_NOR config needed for M25P80
- Enable coherent higher address memory space
----------------------------------------------------------------
Brian Norris (1):
ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80)
Lad Prabhakar (1):
ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG
Santosh Shilimkar (2):
ARM: keystone: Switch over to coherent memory address space
ARM: keystone: Update the dma offset for non-dt platform devices
arch/arm/configs/integrator_defconfig | 1 -
arch/arm/configs/keystone_defconfig | 2 +-
arch/arm/configs/sunxi_defconfig | 1 -
arch/arm/configs/vt8500_v6_v7_defconfig | 1 -
arch/arm/mach-keystone/keystone.c | 74 +++++++++++++++++++++++++++++++
arch/arm/mach-keystone/memory.h | 24 ++++++++++
arch/arm/mach-keystone/platsmp.c | 18 +++++++-
7 files changed, 116 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-keystone/memory.h
Regards,
Santosh
[1] https://lkml.org/lkml/2014/5/7/368
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-05-12 16:38 Santosh Shilimkar
0 siblings, 0 replies; 88+ messages in thread
From: Santosh Shilimkar @ 2014-05-12 16:38 UTC (permalink / raw)
To: linux-arm-kernel
>From 14f3791439b5a6cf12127fb80204265533d92664 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 12 May 2014 12:28:23 -0400
Subject: [GIT PULL 1/2] ARM: Keystone SOC updates for 3.16
Hi Arm-soc folks,
Please pull below keystone SOC updates for 3.16. It merges cleanly with
arm-soc 'next/soc' head. As already discussed, the $subject pull request
has a depedency with DT dma-properties pull request [1] I sent last week
to be pulled into arm-soc.
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-soc
for you to fetch changes up to 14f3791439b5a6cf12127fb80204265533d92664:
ARM: keystone: Update the dma offset for non-dt platform devices (2014-05-08 15:43:33 -0400)
----------------------------------------------------------------
Keystone SOC updates for 3.16
- Drop unused COMMON_CLK_DEBUG option
- Enable MTD_SPI_NOR config needed for M25P80
- Enable coherent higher address memory space
----------------------------------------------------------------
Brian Norris (1):
ARM: configs: keystone: add MTD_SPI_NOR (new dependency for M25P80)
Lad Prabhakar (1):
ARM: configs: keystone: drop CONFIG_COMMON_CLK_DEBUG
Santosh Shilimkar (2):
ARM: keystone: Switch over to coherent memory address space
ARM: keystone: Update the dma offset for non-dt platform devices
arch/arm/configs/integrator_defconfig | 1 -
arch/arm/configs/keystone_defconfig | 2 +-
arch/arm/configs/sunxi_defconfig | 1 -
arch/arm/configs/vt8500_v6_v7_defconfig | 1 -
arch/arm/mach-keystone/keystone.c | 74 +++++++++++++++++++++++++++++++
arch/arm/mach-keystone/memory.h | 24 ++++++++++
arch/arm/mach-keystone/platsmp.c | 18 +++++++-
7 files changed, 116 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-keystone/memory.h
Regards,
Santosh
[1] https://lkml.org/lkml/2014/5/7/368
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-02-22 15:53 Hans de Goede
0 siblings, 0 replies; 88+ messages in thread
From: Hans de Goede @ 2014-02-22 15:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here is v7 of my patchset for adding ahci-sunxi support. This is hopefully
the final final version of this set :)
Note I'm going on vacation for a week starting Monday, so if I'm not responding
that is why. Tejun if you feel some small cleanups are still necessary and
you don't want to wait for me to get back feel free to squash in any cleanups
you deem necessary.
This has been tested with Allwinner A10, Allwinner A20 and Freeware imx6x SoCs,
including suspend / resume. Note that the ahci_imx driver now also has imx53
sata support, it would be good if someone could test that with this series.
History:
v1, by Olliver Schinagl:
This was using the approach of having a platform device which probe method
creates a new child platform device which gets driven by ahci_platform.c,
as done by ahci_imx.c .
v2, by Hans de Goede:
Stand-alone platform driver based on Olliver's work
v3, by Hans de Goede:
patch-series, with 4 different parts
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
regulator
b) New ahci-sunxi code only populating ahci_platform_data, passed to
ahci_platform.c to of_device_id matching.
c) Refactor ahci-imx code to work the same as the new ahci-sunxi code, this
is the reason why v3 is an RFC, I'm waiting for the wandboard I ordered to
arrive so that I can actually test this.
d) dts bindings for the sunxi ahci parts
v4, by Hans de Goede:
patch-series, with 5 different parts:
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
regulator
b) Turn parts of ahci_platform.c into a library for use by other drivers
c) New ahci-sunxi driver using the ahci_platform.c library functionality
d) Refactor ahci-imx code to work the same as the new ahci-sunxi code
e) dts bindings for the sunxi ahci parts
v5:
v4 + the following changes:
1) fsl,imx6q driver is now tested
2) fixed suspend / resume on fsl,imx6q
3) Modifed devicetree node naming to match dt spec
4) Reworked the busy waiting code in the sunxi-phy handling as suggested by
Russell King
v6:
v5 rebased on top of 3.14-rc3 + the following changes
1) Added Roger Quadros' generic phy support series
2) Added a "ARM: sun4i: dt: Remove grouping + simple-bus for regulators" dts
patch
v7:
v6 + the following changes:
1) Addressed all Tejun's review remarks:
* Added function header comments to all exported ahci_platform functions
* Added comments in some other places
* Removed use of 2 empty lines to separate functions in some cases
* Use devres to automatically call ahci_platform_put_resources on
get_resource failure, probe failure and regular device remove
2) Dropped patches to move ahci_host_priv struct declaration to include/linux,
this was a left-over from v3 and is no longer necessary
3) Updated Roger's "ata: ahci_platform: Manage SATA PHY" patch:
* Update function header comments for the changes this makes
* Drop the Kconfig PHY requires hack, my patch for the phy-core to always be
built-in has been queued in Greg KH's tree, so this is no longer necessary.
4) Dropped Roger's "ata: ahci_platform: Add 'struct device' argument to ahci_platform_put_resources()"
patch, ahci_platform_put_resources already has a device argument as result
of it being changed into a devres release function
Tejun, can you please add patches 1-12 to your ata tree for 3.15 ?
Maxime, can you please add patch 13-15 to your dts tree for 3.15 ?
Thanks & Regards,
Hans
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-01-21 4:09 John Tobias
0 siblings, 0 replies; 88+ messages in thread
From: John Tobias @ 2014-01-21 4:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guys,
Just wondering if you encountered the error below and if there's any
existing patch?.
Regards,
john
[ 860.354231] Unable to handle kernel paging request at virtual
address eaffff9d
[ 860.361466] pgd = bf190000
[ 860.364177] [eaffff9d] *pgd=00000000
[ 860.367773] Internal error: Oops: 5 [#1] ARM
[ 860.372048] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
[ 860.377597] CPU: 0 PID: 82 Comm: ksdioirqd/mmc1 Tainted: G
O 3.13.0-rc1 #1
[ 860.385344] task: bf05c280 ti: bf01a000 task.ti: bf01a000
[ 860.390756] PC is at mmc_io_rw_extended+0x38/0x310
[ 860.395552] LR is at mmc_io_rw_extended+0x38/0x310
[ 860.400346] pc : [<80319b68>] lr : [<80319b68>] psr: 400f0013
[ 860.400346] sp : bf01bc90 ip : bf01bd60 fp : bf01bd8c
[ 860.411824] r10: 806f9748 r9 : bf9e7800 r8 : eb075fb4
[ 860.417051] r7 : eaffff9d r6 : 80327c24 r5 : 1a000009 r4 : 00000007
[ 860.423580] r3 : 00000000 r2 : ffffffc4 r1 : 00000000 r0 : bf01bd1c
[ 860.430112] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 860.437423] Control: 10c53c7d Table: bf190059 DAC: 00000015
[ 860.443172] Process ksdioirqd/mmc1 (pid: 82, stack limit = 0xbf01a238)
[ 860.449702] Stack: (0xbf01bc90 to 0xbf01c000)
[ 860.454065] bc80: 80319e04
00000440 00000139 00000000
[ 860.462246] bca0: 00000139 00000000 817de8c2 000000c0 00000700
beac60c0 3b9aca00 00000000
[ 860.470427] bcc0: 00000100 00000007 00000000 00000200 00000700
00000000 bf01bd1c 00000001
[ 860.478609] bce0: bf01bca8 00000000 00000035 1a001207 00002000
00000000 00000000 00000000
[ 860.486790] bd00: 000001b5 00000000 00000000 00000000 00000000
bf01bcb8 bf01bd1c 00000000
[ 860.494971] bd20: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.503153] bd40: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.511334] bd60: bf01bd94 bf01bd70 80324254 80327c24 bf01be04
bf9e7800 806f9748 b600003f
[ 860.519515] bd80: bf01bdd4 bf01bd90 8031ade8 80319b3c bf01be04
80327c24 00000007 1a000009
[ 860.527697] bda0: bf05c280 000001ff 00100100 bfb52000 00000100
00000007 beac60c0 00010009
[ 860.535878] bdc0: 7f03e578 c0adb000 bf01bdec bf01bdd8 8031aef8
8031ad10 beac60c0 00000700
[ 860.544059] bde0: bf01be14 bf01bdf0 7f08c2bc 8031aee0 00000000
00000009 00000700 7f03d328
[ 860.552240] be00: bfad9a00 00000000 bf01be24 bf01be18 7f0622f0
7f08c278 bf01be6c bf01be28
[ 860.560422] be20: 7f0137a8 7f0622ec bf01be44 bf01be38 8004efd4
00000001 bf01be5c 00000000
[ 860.568603] be40: 804fc960 c0adb000 c0adbce4 7f03d328 00000000
7f03e578 7f061dec bfb52000
[ 860.576784] be60: bf01beac bf01be70 7f001e68 7f0134f8 00000000
00000000 00000000 00000000
[ 860.584965] be80: 00000000 bfb52000 7f09a0d4 bfb51800 00000000
bf9e7800 bf01a000 00000001
[ 860.593146] bea0: bf01bec4 bf01beb0 7f05a138 7f001ce0 00000001
00000000 bf01bed4 bf01bec8
[ 860.601327] bec0: 7f08bfe4 7f05a0cc bf01bf24 bf01bed8 8031ba0c
7f08bfc4 00000000 bf01bef3
[ 860.609509] bee0: bfb51800 00000001 bf9e7bb4 7fffffff 0215d9c0
00000001 8031b874 00000000
[ 860.617690] bf00: bf15d9c0 bf9e7800 8031b874 00000000 00000000
00000000 bf01bfac bf01bf28
[ 860.625871] bf20: 8003c7e8 8031b880 bf01bf44 00000000 8004efd4
bf9e7800 00000000 00000001
[ 860.634052] bf40: dead4ead ffffffff ffffffff 80702208 00000000
00000000 80600be8 bf01bf5c
[ 860.642233] bf60: bf01bf5c 00000000 00000001 dead4ead ffffffff
ffffffff 80702208 00000000
[ 860.650415] bf80: 00000000 80600be8 bf01bf88 bf01bf88 bf15d9c0
8003c724 00000000 00000000
[ 860.658595] bfa0: 00000000 bf01bfb0 8000f308 8003c730 00000000
00000000 00000000 00000000
[ 860.666776] bfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 860.674956] bfe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[ 860.683133] Backtrace:
[ 860.685607] [<80319b30>] (mmc_io_rw_extended+0x0/0x310) from
[<8031ade8>] (sdio_io_rw_ext_helper+0xe4/0x1a4)
[ 860.695442] [<8031ad04>] (sdio_io_rw_ext_helper+0x0/0x1a4) from
[<8031aef8>] (sdio_readsb+0x24/0x2c)
[ 860.704676] [<8031aed4>] (sdio_readsb+0x0/0x2c) from [<7f08c2bc>]
(woal_read_data_sync+0x50/0x8c [sd8xxx])
[ 860.714455] [<7f08c26c>] (woal_read_data_sync+0x0/0x8c [sd8xxx])
from [<7f0622f0>] (moal_read_data_sync+0x10/0x14 [sd8xxx])
[ 860.725586] r8:00000000 r7:bfad9a00 r6:7f03d328 r5:00000700 r4:00000009
r3:00000000
[ 860.733603] [<7f0622e0>] (moal_read_data_sync+0x0/0x14 [sd8xxx])
from [<7f0137a8>] (wlan_process_int_status+0x2bc/0x928 [mlan])
[ 860.745139] [<7f0134ec>] (wlan_process_int_status+0x0/0x928 [mlan])
from [<7f001e68>] (mlan_main_process+0x194/0x750 [mlan])
[ 860.756436] [<7f001cd4>] (mlan_main_process+0x0/0x750 [mlan]) from
[<7f05a138>] (woal_interrupt+0x78/0x94 [sd8xxx])
[ 860.766982] [<7f05a0c0>] (woal_interrupt+0x0/0x94 [sd8xxx]) from
[<7f08bfe4>] (woal_sdio_interrupt+0x2c/0x30 [sd8xxx])
[ 860.777677] r5:00000000 r4:00000001
[ 860.781351] [<7f08bfb8>] (woal_sdio_interrupt+0x0/0x30 [sd8xxx])
from [<8031ba0c>] (sdio_irq_thread+0x198/0x368)
[ 860.791537] [<8031b874>] (sdio_irq_thread+0x0/0x368) from
[<8003c7e8>] (kthread+0xc4/0xe0)
[ 860.799814] [<8003c724>] (kthread+0x0/0xe0) from [<8000f308>]
(ret_from_fork+0x14/0x2c)
[ 860.807818] r7:00000000 r6:00000000 r5:8003c724 r4:bf15d9c0
[ 860.813538] Code: e1a09003 e59b400c e59b5010 ebfc3a75 (e5973000)
[ 860.819646] ---[ end trace 1920724507aeb8b4 ]---
[ 860.824270] Kernel panic - not syncing: Fatal exception
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-01-16 16:11 Loc Ho
0 siblings, 0 replies; 88+ messages in thread
From: Loc Ho @ 2014-01-16 16:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for the APM X-Gene SoC SATA host controller. In
order for the host controller to work, the corresponding PHY driver
musts also be available.
v10:
* Update binding documentation
v9:
* Remove ACPI/EFI include files
* Remove the IO flush support, interrupt routine, and DTS resources
* Remove function xgene_rd, xgene_wr, and xgene_wr_flush
* Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
* Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
* Clean up hardreset functions
* Require v7 of the PHY driver
v8:
* Remove _ADDR from defines
* Remove define MSTAWAUX_COHERENT_BYPASS_SET and
STARAUX_COHERENT_BYPASS_SET and use direct coding
* Remove the un-necessary check for DTS boot with built in ACPI table
* Switch to use dma_set_mask_and_coherent for setting DMA mask
* Remove ACPI table matching code
* Update clock-names for sata01clk, sata23clk, and sata45clk
v7:
* Update the clock code by toggle the clock
* Update the DTS clock mask values due to the clock spilt between host and
v5 of the PHY drivers
v6:
* Update binding documentation
* Change select PHY_XGENE_SATA to PHY_XGENE
* Add ULL to constants
* Change indentation and comments
* Clean up the probe functions a bit more
* Remove xgene_ahci_remove function
* Add the flush register to DTS
* Remove the interrupt-parent from DTS
v5:
* Sync up to v3 of the PHY driver
* Remove MSLIM wrapper functions
* Change the memory shutdown loop to use usleep_range
* Use devm_ioremap_resource instead devm_ioremap
* Remove suspend/resume functions as not needed
v4:
* Remove the ID property in DT
* Remove the temporary PHY direct function call and use PHY function
* Change printk to pr_debug
* Move the IOB flush addresses into the DT
* Remove the parameters retrieval function as no longer needed
* Remove the header file as no longer needed
* Require v2 patch of the SATA PHY driver. Require slightly modification
in the Kconfig as it is moved to folder driver/phy and use Kconfig
PHY_XGENE_SATA instead SATA_XGENE_PHY.
v3:
* Move out the SATA PHY to another driver
* Remove the clock-cells entry from DTS
* Remove debug wrapper
* Remove delay functions wrapper
* Clean up resource and IRQ query
* Remove query clock name
* Switch to use dma_set_mask/dma_coherent_mask
* Remove un-necessary devm_kfree
* Update GPL license header to v2
* Spilt up function xgene_ahci_hardreset
* Spilt up function xgene_ahci_probe
* Remove all reference of CONFIG_ARCH_MSLIM
* Clean up chip revision code
v2:
* Clean up file sata_xgene.c with Lindent and etc
* Clean up file sata_xgene_serdes.c with Lindent and etc
* Add description to each patch
v1:
* inital version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
ata: Export required functions by APM X-Gene SATA driver
Documentation: Add documentation for APM X-Gene SoC SATA host
controller DTS binding
ata: Add APM X-Gene SoC SATA host controller driver
arm64: Add APM X-Gene SoC SATA host controller DTS entries
.../devicetree/bindings/ata/apm-xgene.txt | 70 +++
arch/arm64/boot/dts/apm-storm.dtsi | 75 +++
drivers/ata/Kconfig | 8 +
drivers/ata/Makefile | 1 +
drivers/ata/ahci.h | 9 +
drivers/ata/libahci.c | 16 +-
drivers/ata/sata_xgene.c | 630 ++++++++++++++++++++
7 files changed, 803 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
create mode 100644 drivers/ata/sata_xgene.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-01-16 16:09 Loc Ho
0 siblings, 0 replies; 88+ messages in thread
From: Loc Ho @ 2014-01-16 16:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.
v8
* Update binding documentation
* Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines
* Remove support for internal clock
* Remove support for external reference CMU
* Remove the need for external reference resource DTS entry and its related
code
v7
* Add/Update PHY CMU/lane parameters and its default values
* Rename variable enable_manual_cal to preA3Chip
* Remove function phy_rd, phy_wr, and phy_wr_flush
* Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits,
serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context
instead void *
* Remove function serdes_toggle1to0
* Decrease the polling time from 10ms to 1ms on CMU calibration complete
detection
* Move all SATA specify code in function xgene_phy_hw_initialize into
function xgene_phy_hw_init_sata
* Add usleep_range after starting summer/latch calibrations
* Add usleep_range between receiver reset (function xgene_phy_reset_rxd)
* Save and restore PHY register 31 instead writing 0 in function
xgene_phy_gen_avg_val
* Update function xgene_phy_sata_force_gen programming sequences
* Add support to reset the receiver lane in function xgene_phy_set_speed
if speed is 0
* Update PHY parameters in DTS per controller
* Some minor code clean up
v6
* Move PHY document to Documentation/devicetree/binding/phy
* Remove _ADDR from all register defines
* Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk
v5
* Update DTS binding documentation
* Remove direct clock access and use clock interface instead
* Change override parameters to decimal instead hex values
* Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2,
apm,tx-post-cursor to be unit of uV
v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values
v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment
v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79 +
arch/arm64/boot/dts/apm-storm.dtsi | 75 +
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-core.c | 21 +
drivers/phy/phy-xgene.c | 1793 ++++++++++++++++++++
include/linux/phy/phy.h | 8 +
7 files changed, 1985 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
create mode 100644 drivers/phy/phy-xgene.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-01-13 10:32 Lothar Waßmann
0 siblings, 0 replies; 88+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the Ka-Ro electronics i.MX53 based
modules.
The first patch adds a new pingroup for NAND pads that is used by the
modules.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2014-01-13 10:29 Lothar Waßmann
0 siblings, 0 replies; 88+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:29 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for inverting the PWM output in hardware by
setting the POUTC bit in the PWMCR register. This feature is
controlled via the standard DT flas for PWMs.
The first patch does a minor source cleanup without any functional
change.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-12-12 7:30 Loc Ho
0 siblings, 0 replies; 88+ messages in thread
From: Loc Ho @ 2013-12-12 7:30 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.
v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values
v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment
v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
.../devicetree/bindings/ata/apm-xgene-phy.txt | 89 +
arch/arm64/boot/dts/apm-storm.dtsi | 31 +
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-core.c | 21 +
drivers/phy/phy-xgene.c | 1854 ++++++++++++++++++++
include/linux/phy/phy.h | 8 +
7 files changed, 2012 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene-phy.txt
create mode 100644 drivers/phy/phy-xgene.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-11-01 7:04 Xiubo Li
0 siblings, 0 replies; 88+ messages in thread
From: Xiubo Li @ 2013-11-01 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver implementation. And the implementation is only compatible with device tree definition.
This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree.
Changed in v2:
- Use default settings for the generic dmaengine PCM driver.
- Separate receive and transmit setting in most functions, but some couldn't for the HW limitation.
- Drop some not reduntant code.
- Use devm_snd_soc_register_component() instead of snd_soc_register_component().
- Use devm_snd_soc_register_card() instead of devm_snd_soc_register_card().
- Adjust the code sentences sequence.
- Make the namespacing consistent.
- Rename CONFIG_SND_SOC_FSL_SGTL5000 to CONFIG_SND_SOC_FSL_SGTL5000_VF610.
- Drop some meaningless lines.
- Rename the binding document file.
Added in v1:
- Add SAI SoC Digital Audio Interface driver.
- Add Freescale SAI ALSA SoC Digital Audio Interface node for VF610.
- Enables SAI ALSA SoC DAI device for Vybrid VF610 TOWER board.
- Add device tree bindings for Freescale SAI.
- Revise the bugs about the sgt15000 codec.
- Add SGT15000 based audio machine driver.
- Enable SGT15000 codec based audio driver node for VF610.
- Add device tree bindings for Freescale VF610 sound.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-09-24 3:13 Rohit Vaswani
0 siblings, 0 replies; 88+ messages in thread
From: Rohit Vaswani @ 2013-09-24 3:13 UTC (permalink / raw)
To: linux-arm-kernel
Date: Mon, 23 Sep 2013 19:51:25 -0700
Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize
the selects for MSM
Create the hidden config DEBUG_MSM_UART and clean-up the default selection
for CONFIG_DEBUG_LL_INCLUDE.
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
---
arch/arm/Kconfig.debug | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..e18a6fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -318,6 +318,7 @@ choice
config DEBUG_MSM_UART1
bool "Kernel low-level debugging messages via MSM UART1"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the first serial port on MSM devices.
@@ -325,6 +326,7 @@ choice
config DEBUG_MSM_UART2
bool "Kernel low-level debugging messages via MSM UART2"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the second serial port on MSM devices.
@@ -332,6 +334,7 @@ choice
config DEBUG_MSM_UART3
bool "Kernel low-level debugging messages via MSM UART3"
depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the third serial port on MSM devices.
@@ -340,6 +343,7 @@ choice
bool "Kernel low-level debugging messages via MSM 8660 UART"
depends on ARCH_MSM8X60
select MSM_HAS_DEBUG_UART_HS
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8660 devices.
@@ -348,6 +352,7 @@ choice
bool "Kernel low-level debugging messages via MSM 8960 UART"
depends on ARCH_MSM8960
select MSM_HAS_DEBUG_UART_HS
+ select DEBUG_MSM_UART
help
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8960 devices.
@@ -880,6 +885,10 @@ config DEBUG_STI_UART
bool
depends on ARCH_STI
+config DEBUG_MSM_UART
+ bool
+ depends on ARCH_MSM
+
config DEBUG_LL_INCLUDE
string
default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
@@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART
- default "debug/msm.S" if DEBUG_MSM_UART1 || \
- DEBUG_MSM_UART2 || \
- DEBUG_MSM_UART3 || \
- DEBUG_MSM8660_UART || \
- DEBUG_MSM8960_UART
+ default "debug/msm.S" if DEBUG_MSM_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
@ 2013-09-02 17:01 Drasko DRASKOVIC
0 siblings, 0 replies; 88+ messages in thread
From: Drasko DRASKOVIC @ 2013-09-02 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
In socfpga.dts I can see following definitions :
/* Local timer */
timer at fffec600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xfffec600 0x100>;
interrupts = <1 13 0xf04>;
};
timer0: timer0 at ffc08000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 167 4>;
reg = <0xffc08000 0x1000>;
};
timer1: timer1 at ffc09000 {
compatible = "snps,dw-apb-timer-sp";
interrupts = <0 168 4>;
reg = <0xffc09000 0x1000>;
};
timer2: timer2 at ffd00000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 169 4>;
reg = <0xffd00000 0x1000>;
};
timer3: timer3 at ffd01000 {
compatible = "snps,dw-apb-timer-osc";
interrupts = <0 170 4>;
reg = <0xffd01000 0x1000>;
};
However, from my board's shell :
root at socfpga_cyclone5:~# cat /proc/interrupts
CPU0 CPU1
525: 24935 24717 GIC twd
648: 801 0 GIC eth0
653: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
656: 0 0 GIC dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb2
667: 163006 0 GIC dw-mci
679: 0 0 GIC ff705000.spi
682: 0 0 GIC dw_spi0
684: 0 0 GIC dw_spi1
686: 6 0 GIC ffc04000.i2c
687: 0 0 GIC ffc05000.i2c
690: 2390 0 GIC serial
697: 9 0 GIC timer2
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 1268 1289 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4: 3 1 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
Err: 0
So, I can see only timer2.
root at socfpga_cyclone5:~# find / -name "timer*"
/proc/timer_list
/proc/device-tree/soc/timer3 at ffd01000
/proc/device-tree/soc/timer2 at ffd00000
/proc/device-tree/soc/timer1 at ffc09000
/proc/device-tree/soc/timer0 at ffc08000
/proc/device-tree/soc/timer at fffec600
/proc/device-tree/aliases/timer3
/proc/device-tree/aliases/timer2
/proc/device-tree/aliases/timer1
/proc/device-tree/aliases/timer0
/sys/kernel/debug/tracing/events/timer
/sys/kernel/debug/tracing/events/timer/timer_cancel
/sys/kernel/debug/tracing/events/timer/timer_expire_exit
/sys/kernel/debug/tracing/events/timer/timer_expire_entry
/sys/kernel/debug/tracing/events/timer/timer_start
/sys/kernel/debug/tracing/events/timer/timer_init
/sys/module/oprofile/parameters/timer
root at socfpga_cyclone5:~#
Where is defined which timer will be present, activated and
initialized on the board - i.e. only timer2 is active in this case,
and I would like to use timer1.
BR,
Drasko
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-08-24 9:29 Haojian Zhuang
0 siblings, 0 replies; 88+ messages in thread
From: Haojian Zhuang @ 2013-08-24 9:29 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
v8:
1. Drop to support CLK_GATE_SEPERATED_REG in common clock gate driver.
Support this feature in hi3xxx clock driver.
2. Clean unnecessary device node in DTS.
3. Define all clocks in hi3620-clk.dtsi. And all clock nodes are defined
in the clocks node.
4. Fix the clock gate & clock mux for timer.
5. Rename timer0~4 to dual_timer0~4 in DTS file. It's used to make
name clearer.
v7:
1. Add hi3xxx_defconfig.
2. Use reg property in clock node.
3. Drop origin clock divider table.
4. Reuse clock divider register helper.
5. Reuse clock gate register helper.
6. Append CLK_GATE_SEPERATED_REG flag in order to support Hisilicon
Hi3620 SoC.
7. Rebase DEBUG_LL for Hi3xxx.
8. Add more clock node in DTS file.
v6:
1. Remove hisilicon string from properties in clock driver.
2. Replace array by pointer in clock driver. Since only sctrl parent
node exists at this time.
v5:
1. Remove HIWORD clk patches since they're merged into clk git tree.
2. Set hisilicon,clk-reset property of clkgate node is optional.
3. Update on commandline args in DTS file. Remove earlyprintk, mem, nfs.
4. Move gpio-keys out of amba node in DTS file.
v4:
1. Add clk gate with HIWORD mask for Rockchip.
2. Update comments and code of HIWORD flags for mux/divider.
3. Append a mux without HIWORD mask in Hisilicon 3620.
4. Fix the pinmux setting in Hi4511.
v3:
1. Use clk_register_mux_table().
v2:
1. Reuse mux & divider driver. So append CLK_MUX_HIWORD_MASK &
CLK_DIVIDER_HIWORD_MASK for Hi3620 SoC.
2. Fix system timer running too fast because wrong divider is choosen.
3. Remove .init_irq in DT machine descriptor.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-07-26 10:05 Haojian Zhuang
0 siblings, 0 replies; 88+ messages in thread
From: Haojian Zhuang @ 2013-07-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
v6:
1. Merge clk apbc & apbcp together.
2. Add DT binding document of clock driver.
3. Remove marvell string in properties of clock driver.
v5:
1. Use clk mux table.
v4:
1. Remove .init_irq in mmp & mmp2 DT machine descriptor.
2. Use an argument to replace TIMER_PHYS_BASE. Now transfer virtual
address directly.
3. Merge 10th & 11th patches together. Remove the redundant changes
on drivers/clocksource/Kconfig & drivers/clocksource/Makefile.
v3:
1. Don't use include/linux/irqchip/mmp.h since we don't need to
move <mach/irqs.h> to <include/linux/irqchip/mmp.h>.
2. Move timer-mmp driver into clocksource directory & support
clocksource.
3. Support clksrc in mmp & parse all clock from DTS.
v2:
1. Avoid to include <mach/irqs.h>. Move the head file into
include/linux/irqchip directory.
2. Avoid to include <mach/pm-pxa910.h> & <mach/pm-mmp2.h>.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-06-28 5:49 Wang, Yalin
0 siblings, 0 replies; 88+ messages in thread
From: Wang, Yalin @ 2013-06-28 5:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sboy,
I don't know who should I send this mail to .
If you are not the right person, please forward
To the right responsible person , Thank you !
I have a question about msm kernel code :
File: Arch/arm/msm/memory.c
reserve_memory_for_mempools()
it call memblock_remove() directly,
I think it's not safe sometimes ,
Should use arm_memblock_steal() function or some other similar
Function to make sure the removed memory is not reserved by memblock driver,
In case the removed memory is reserved by some driver.
Thanks
Yalin.Wang
Software Engineer
OS Kernel&Graphics
?
Sony Mobile Communications
Tel: +86 10 5966 9819
Phone: 18610323092
Address: No.16 Guangshun South Street, Chaoyang, Beijing, P.R.C.
sonymobile.com
??
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-06-19 10:57 Ben Dooks
0 siblings, 0 replies; 88+ messages in thread
From: Ben Dooks @ 2013-06-19 10:57 UTC (permalink / raw)
To: linux-arm-kernel
I found this one whilst testing versatile-express with a -rc kernel
and was considering if this is the correct way to fix this.
[PATCH] atags_to_fdt: take into account root's #size and #cells
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2013-04-24 18:07 Viral Mehta
0 siblings, 0 replies; 88+ messages in thread
From: Viral Mehta @ 2013-04-24 18:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I am using Marvell's ARMADA XP platform in my development environment.
Recently, I faced DMA related issue. While moving data from memory to
the device, I found that sometimes I am getting Junk data. I looked
further to see if this is related to DMA Sync problem. So, basically,
I have following questions,
1. As per [1] ARMADA has Coherency Fabric that sits between CPU and
other devices and takes care of hardware based I/O cache coherency. Do
we need to enable any support for the same in software ? I am running
3.0.29 based linux kernel. How do I verify that I have all the things
enabled in Linux Kernel.
2. Do I still need to use dma_[map,unamp]_* APIs while copying data to
and from device ?
[1] http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
--
Thanks,
Viral Mehta
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-12-29 9:17 steve.zhan
0 siblings, 0 replies; 88+ messages in thread
From: steve.zhan @ 2012-12-29 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
It is good idea add this feature.
1: Can we let the "ret = hwspin_lock_tests(ops, hwlock);" add after
hwspin_lock_register_single have return
succeed, that can avoid test duplicated Or error lockid. Of course, If
this interface is intend to test soc hardware capability only, we can
put it in the arch module not this core framework. For driver hardware
sanity check, i would add it after software have register it.
2:Is it possible that interface add configs that choose which locks
will be test? Because the hwspinlock module is init late in
postcore_initcall phase, Maybe MACH/ARCH code(for example: code in
early_initcall) need use private other interfaces to lock some
hwspinlocks and then register hw locks to hwspinlock framework, Maybe
some hw locks is in lock status but which test failed.
--
Steve Zhan
> From: Ido Yariv <ido@wizery.com>
> To: Ohad Ben-Cohen <ohad@wizery.com>, linux-kernel at vger.kernel.org,
> linux-arm-kernel at lists.infradead.org, linux-omap at vger.kernel.org
> Cc: Ido Yariv <ido@wizery.com>
> Subject: [PATCH] hwspinlock/core: Add testing capabilities
> Message-ID: <1355344026-17222-1-git-send-email-ido@wizery.com>
>
> Add testing capabilities for verifying correctness of the underlying
> hwspinlock layers. This can be handy especially during development.
> These tests are performed only once as part of the hwspinlock
> registration.
>
> Signed-off-by: Ido Yariv <ido@wizery.com>
> ---
> drivers/hwspinlock/Kconfig | 9 +++++
> drivers/hwspinlock/hwspinlock_core.c | 54
> ++++++++++++++++++++++++++++++++++
> 2 files changed, 63 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index c7c3128..ad632cd 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -8,6 +8,15 @@ config HWSPINLOCK
>
> menu "Hardware Spinlock drivers"
>
> +config HWSPINLOCK_TEST
> + bool "Verify underlying hwspinlock implementation"
> + depends on HWSPINLOCK
> + help
> + Say Y here to perform tests on the underlying hwspinlock
> + implementation. The tests are only performed once per implementation.
> +
> + Say N, unless you absolutely know what you are doing.
> +
> config HWSPINLOCK_OMAP
> tristate "OMAP Hardware Spinlock device"
> depends on ARCH_OMAP4
> diff --git a/drivers/hwspinlock/hwspinlock_core.c
> b/drivers/hwspinlock/hwspinlock_core.c
> index 085e28e..1874e85 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -307,6 +307,53 @@ out:
> return hwlock;
> }
>
> +#ifdef CONFIG_HWSPINLOCK_TEST
> +#define NUM_OF_TEST_ITERATIONS 100
> +static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
> + struct hwspinlock *hwlock)
> +{
> + int i;
> + int ret;
> +
> + for (i = 0; i < NUM_OF_TEST_ITERATIONS; i++) {
> + ret = ops->trylock(hwlock);
> + if (!ret) {
> + pr_err("%s: Initial lock failed\n", __func__);
> + return -EFAULT;
> + }
> +
> + /* Verify lock actually works - re-acquiring it should fail */
> + ret = ops->trylock(hwlock);
> + if (ret) {
> + /* Keep locks balanced even in failure cases */
> + ops->unlock(hwlock);
> + ops->unlock(hwlock);
> + pr_err("%s: Recursive lock succeeded unexpectedly\n",
> + __func__);
> + return -EFAULT;
> + }
> +
> + /* Verify unlock by re-acquiring the lock after releasing it */
> + ops->unlock(hwlock);
> + ret = ops->trylock(hwlock);
> + if (!ret) {
> + pr_err("%s: Unlock failed\n", __func__);
> + return -EINVAL;
> + }
> +
> + ops->unlock(hwlock);
> + }
> +
> + return 0;
> +}
> +#else /* CONFIG_HWSPINLOCK_TEST*/
> +static int hwspin_lock_tests(const struct hwspinlock_ops *ops,
> + struct hwspinlock *hwlock)
> +{
> + return 0;
> +}
> +#endif
> +
> /**
> * hwspin_lock_register() - register a new hw spinlock device
> * @bank: the hwspinlock device, which usually provides numerous hw locks
> @@ -345,6 +392,13 @@ int hwspin_lock_register(struct hwspinlock_device
> *bank, struct device *dev,
> spin_lock_init(&hwlock->lock);
> hwlock->bank = bank;
>
> + ret = hwspin_lock_tests(ops, hwlock);
> + if (ret) {
> + pr_err("hwspinlock tests failed on lock %d\n",
> + base_id + i);
> + goto reg_failed;
> + }
> +
> ret = hwspin_lock_register_single(hwlock, base_id + i);
> if (ret)
> goto reg_failed;
> --
> 1.7.7.6
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-11-08 8:07 Abhimanyu Kapur
0 siblings, 0 replies; 88+ messages in thread
From: Abhimanyu Kapur @ 2012-11-08 8:07 UTC (permalink / raw)
To: linux-arm-kernel
subscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121108/ea49c32b/attachment-0001.html>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-10-14 10:05 Alexey Dobriyan
0 siblings, 0 replies; 88+ messages in thread
From: Alexey Dobriyan @ 2012-10-14 10:05 UTC (permalink / raw)
To: linux-arm-kernel
http://www.hzsonic.com/en/wp-content/themes/twentyten/career.html
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-08-27 6:40 Simon Horman
0 siblings, 0 replies; 88+ messages in thread
From: Simon Horman @ 2012-08-27 6:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Hi Olaf,
please consider the following enhancements for the Armadillo800EVA board
from Laurent Pinchart for inclusion in 3.7.
I am currently in the processes of taking over maintenance
of shmoble from Rafael Wysocki and this my the first pull request
in that role.
----------------------------------------------------------------
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git armadillo800eva
for you to fetch changes up to 5c1d2d16772e2d7d4e2e8da99a92d6f50b9102f0:
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source (2012-08-25 15:44:53 +0900)
----------------------------------------------------------------
Laurent Pinchart (2):
ARM: mach-shmobile: armadillo800eva: Fix GPIO buttons descriptions
ARM: mach-shmobile: armadillo800eva: Enable power button as wakeup source
arch/arm/mach-shmobile/board-armadillo800eva.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-06-21 18:26 Paul Walmsley
0 siblings, 0 replies; 88+ messages in thread
From: Paul Walmsley @ 2012-06-21 18:26 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
- ----------------------------------------------------------------
Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
- ----------------------------------------------------------------
Testing logs are available at
http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/
The summary is that 5912OSK NFS root and N800 MMC don't boot to
userspace; this broke between v3.4-rc2 and v3.5-rc3. 3517 boards are
still broken with NFS root and also several stack tracebacks during
boot. In terms of PM, core isn't entering idle on OMAP3 or OMAP4.
These problems all exist in v3.5-rc3 - they aren't caused by this
series.
object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)):
text data bss total kernel
0 0 0 0 5912osk_testconfig/vmlinux
+4636 -400 0 +4236 am33xx_testconfig/vmlinux
+440 -408 +32 +64 n800_multi_omap2xxx/vmlinux
+416 -192 +32 +256 n800_testconfig/vmlinux
0 0 0 0 omap1510_defconfig/vmlinux
0 0 0 0 omap1_defconfig/vmlinux
+732 -456 0 +276 omap2_4_testconfig/vmlinux
+4776 -624 0 +4152 omap2plus_defconfig/vmlinux
+684 -664 0 +20 omap2plus_no_pm/vmlinux
+616 -336 +64 +344 omap3_4_testconfig/vmlinux
+360 -384 0 -24 omap3_testconfig/vmlinux
+580 -120 +64 +524 omap4_testconfig/vmlinux
Kevin Hilman (7):
ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module()
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable()
ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready
ARM: OMAP2+: hwmod: use init-time function pointer for hardreset
ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm
ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
Omar Ramirez Luna (2):
ARM: OMAP2+: control: new APIs to configure boot address and mode
ARM: OMAP: dsp: interface to control module functions
Paul Walmsley (2):
ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6
Peter Ujfalusi (3):
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430
ARM: OMAP3: Move McBSP fck clock alias to hwmod data
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/clock2420_data.c | 4 -
arch/arm/mach-omap2/clock2430_data.c | 10 -
arch/arm/mach-omap2/clock3xxx_data.c | 10 -
arch/arm/mach-omap2/clockdomain.h | 2 -
arch/arm/mach-omap2/clockdomains2420_data.c | 2 -
arch/arm/mach-omap2/clockdomains2430_data.c | 2 -
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 -
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
arch/arm/mach-omap2/control.c | 43 ++
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/dsp.c | 4 +
.../include/mach/ctrl_module_core_44xx.h | 1 +
arch/arm/mach-omap2/omap_hwmod.c | 427 ++++++++++++++------
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 +-
arch/arm/plat-omap/include/plat/clock.h | 2 -
arch/arm/plat-omap/include/plat/dsp.h | 3 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
22 files changed, 409 insertions(+), 187 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJP42cFAAoJEMePsQ0LvSpLmMAP/06LRRSFBPklr2hDmFPKBfBD
guF3rAN5zimEyknXp1RhoHJjcH0YCkUdQgD24w51yVwVB9zVW0M6G9hVi91cJj9X
1StRIwTbtb08yPdOlpywEXzHpjXz3AauCMRRxYJHi0FjajwHNKWWv+A/iolM0p8P
5o5ZY+D3AzJqfX/+A0FK2YKn2Z7X9kxg8uTTukhXhe38ldZJ2pHqA4ND2n2F+GnD
DUGqpnYu+QLTmw0x0NbpTNDarnmUEa/tH1NRny5Fh+ujYxH5NPTVvxHTW8tbm5bl
qkleWJaDc+D2pCnD3ch3cUlLgIfTZbo4KUg+Y4uv4QLrLx/QTu6TpyJaP+ZJw3sY
amakgmv3vzYzHMOf/0gxIe6xDZl6YFVXiOdJex4kQ5qodXRgmh82gYUrEKLLHuWn
+EKwIBM8xV5zYzA60vZ05ul7QqeNfwD5D6dd5As96QweVJFMGiIDWINGfxOtI/mH
ygXD6sSZvYhqGk2EVb+hje971urmI4aIrolt/xB4anOATiehaJuwhLjtp+5ZO7tL
5w3bybiUqKh+CN0DlpL/Srw0jaVp/pjZE8+4tzw/Mvm5T8wSVZL2ysJfmX4WffKl
k7RI46jiiQfFLJbSF5pgXUEm00/Ut3g7otp2F+iZLuAplJwoojl7cgezTSAgRc9E
Rhv07SsL5AAZ5OyCOdeQ
=rQK5
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-06-06 10:33 Sascha Hauer
0 siblings, 0 replies; 88+ messages in thread
From: Sascha Hauer @ 2012-06-06 10:33 UTC (permalink / raw)
To: linux-arm-kernel
The following adds i.MX53 nand support and generally devicetree
based probing for i.MX5 boards. The first three patches should go
via mtd, the last patch optionally aswell if all agree.
Sascha
The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:
Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/imx/linux-2.6.git imx/nand-mx53
for you to fetch changes up to d55d1479a3bfaedbb9f0c6c956f4dff6bb6d6d61:
ARM i.MX5: Add nand oftree support (2012-06-06 12:20:24 +0200)
----------------------------------------------------------------
Sascha Hauer (4):
mtd nand mxc_nand: Use managed resources
mtd nand mxc_nand: swap iomem resource order
mtd nand mxc_nand: add i.MX53 support
ARM i.MX5: Add nand oftree support
arch/arm/boot/dts/imx51.dtsi | 7 ++
arch/arm/boot/dts/imx53.dtsi | 7 ++
arch/arm/mach-imx/clk-imx51-imx53.c | 2 +
arch/arm/plat-mxc/devices/platform-mxc_nand.c | 11 +-
drivers/mtd/nand/mxc_nand.c | 137 ++++++++++++++-----------
5 files changed, 97 insertions(+), 67 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-05-18 12:27 Sascha Hauer
0 siblings, 0 replies; 88+ messages in thread
From: Sascha Hauer @ 2012-05-18 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.
Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.
Comments very welcome.
Thanks
Sascha
----------------------------------------------------------------
Sascha Hauer (2):
DRM: add Freescale i.MX LCDC driver
pcm038 lcdc support
arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 ++
arch/arm/boot/dts/imx27.dtsi | 7 +
arch/arm/mach-imx/clock-imx27.c | 1 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/imx/Kconfig | 18 +
drivers/gpu/drm/imx/Makefile | 8 +
drivers/gpu/drm/imx/imx-drm-core.c | 745 ++++++++++++++++++++++++++++
drivers/gpu/drm/imx/imx-fb.c | 179 +++++++
drivers/gpu/drm/imx/imx-fbdev.c | 275 ++++++++++
drivers/gpu/drm/imx/imx-gem.c | 343 +++++++++++++
drivers/gpu/drm/imx/imx-lcdc-crtc.c | 517 +++++++++++++++++++
drivers/gpu/drm/imx/imx-parallel-display.c | 228 +++++++++
13 files changed, 2363 insertions(+)
create mode 100644 drivers/gpu/drm/imx/Kconfig
create mode 100644 drivers/gpu/drm/imx/Makefile
create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
create mode 100644 drivers/gpu/drm/imx/imx-fb.c
create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
create mode 100644 drivers/gpu/drm/imx/imx-gem.c
create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2012-03-20 18:28 John Szakmeister
0 siblings, 0 replies; 88+ messages in thread
From: John Szakmeister @ 2012-03-20 18:28 UTC (permalink / raw)
To: linux-arm-kernel
We've been running into several issues on the cache flushing front,
and I'm hoping that someone here can help clarify what should be
happening from a kernel perspective.
Late last year we discovered a few interesting problems. One of them
is definitely our fault: we weren't flushing the cache after we read
data from a block device a wrote it into the page. However, there was
another issue we noticed that made less sense: we had to flush a page
before writing it to our block device, otherwise we end up writing
some stale data. The brd device ran into this issue before, and fixed
it in commit c2572f2b[1]. In that commit Nick Pidgin says:
"brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the
pagecache's responsibility to flush user virtual aliases (the driver of
course should flush kernel virtual mappings)... but anyway, there
already exists cache flushing for one direction of transfer, so we
should add the other."
I can't help but to feel he's right. It was very surprising to me
that I had to flush the user virtual aliases before writing the data
to the device. Is it expected that we (as device driver writers) have
to do that for block device drivers? I love Linux, but one of the
aspects I find most frustrating is that I don't know what I can safely
assume at interface boundaries. Even modeling my work after existing
code yields problems, because a number of drivers in the tree seem to
be broken in this regard.
But it leads to another concern. Since I do have to flush on writes,
it got me thinking about whether it's necessary to flush user mode
aliases before conducting a read. Consider the fact that a page can
span multiple blocks. Is it possible that:
* we're asked to read a block of data
* a user app has scribbled on the page (so it's dirty, but not flushed)
* we read the requested data from the device
* load it into the page
* do a flush_dcache_page()
* then the data read from the device becomes corrupt because cached user data
is written to RAM?
Or, instead of that, the cached data gets dropped entirely because it
was on the page, but shouldn't have been because we didn't read new
data into that area, and now that user data is lost? I confess this
may all be my lack of understanding about Linux's block i/o subsystem,
but I'm thoroughly confused at this point. What I do know is that
other device drivers are not flushing the page before writing the data
to a device. For instance, the mmc driver for the at91 architecture
suffers from this problem, and I've been able to see that problem
using mmap. My concern is that many other drivers also suffer from
this problem, so I'm not sure what the fix needs to be: fix the page
cache, fix the driver, or both.
Also, is there somewhere that says what's guaranteed on entry into my
block device driver? I've scoured everything I could find... the
Documentation area (including cachetlb.txt), Linux sites, books...
I've yet to find anything mentioning the need to call
flush_dcache_page() much less talk about what the assumptions are.
Thanks in advance for the help.
-John
[1]: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c2572f2b4ffc27ba79211aceee3bef53a59bb5cd>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-12-28 14:01 Shawn Guo
0 siblings, 0 replies; 88+ messages in thread
From: Shawn Guo @ 2011-12-28 14:01 UTC (permalink / raw)
To: linux-arm-kernel
[Resend to cc LAKML. Sorry.]
Hi Arnd, Olof,
Please consider to pull mxs/clk-prepare for 3.3. I have not collected
the ack tag from every single subsystem maintainer, but I do not want
to hold this any longer, since it's close to merge window now.
Hi Sascha,
I send a couple of Richard's patch you have collected here for
completeness.
Regards,
Shawn
The following changes since commit 384703b8e6cd4c8ef08512e596024e028c91c339:
Linux 3.2-rc6 (2011-12-16 18:36:26 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git mxs/clk-prepare
Richard Zhao (2):
clk: add helper functions clk_prepare_enable and clk_disable_unprepare
net: fec: add clk_prepare/clk_unprepare
Shawn Guo (10):
ARM: mxs: convert platform code to clk_prepare/clk_unprepare
dma: mxs-dma: convert to clk_prepare/clk_unprepare
mmc: mxs-mmc: convert to clk_prepare/clk_unprepare
mtd: gpmi-lib: convert to clk_prepare/clk_unprepare
net: flexcan: convert to clk_prepare/clk_unprepare
serial: mxs-auart: convert to clk_prepare/clk_unprepare
video: mxsfb: convert to clk_prepare/clk_unprepare
ASoC: mxs-saif: convert to clk_prepare/clk_unprepare
clk: add config option HAVE_CLK_PREPARE into Kconfig
ARM: mxs: select HAVE_CLK_PREPARE for clock
arch/arm/Kconfig | 1 +
arch/arm/mach-mxs/clock-mx23.c | 10 +++++-----
arch/arm/mach-mxs/clock-mx28.c | 10 +++++-----
arch/arm/mach-mxs/clock.c | 33 +++++++++++++++++++++++----------
arch/arm/mach-mxs/mach-mx28evk.c | 2 +-
arch/arm/mach-mxs/system.c | 2 +-
arch/arm/mach-mxs/timer.c | 2 +-
drivers/clk/Kconfig | 3 +++
drivers/dma/mxs-dma.c | 8 ++++----
drivers/mmc/host/mxs-mmc.c | 10 +++++-----
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 12 ++++++------
drivers/net/can/flexcan.c | 10 +++++-----
drivers/net/ethernet/freescale/fec.c | 10 +++++-----
drivers/tty/serial/mxs-auart.c | 8 ++++----
drivers/video/mxsfb.c | 8 ++++----
include/linux/clk.h | 22 ++++++++++++++++++++++
sound/soc/mxs/mxs-saif.c | 4 ++--
17 files changed, 97 insertions(+), 58 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-12-02 16:01 Will Deacon
0 siblings, 0 replies; 88+ messages in thread
From: Will Deacon @ 2011-12-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-11-28 2:35 Jett.Zhou
0 siblings, 0 replies; 88+ messages in thread
From: Jett.Zhou @ 2011-11-28 2:35 UTC (permalink / raw)
To: linux-arm-kernel
1 remove unnecesary spinlock when release
2 remove change id
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-09-19 1:45 Saleem Abdulrasool
0 siblings, 0 replies; 88+ messages in thread
From: Saleem Abdulrasool @ 2011-09-19 1:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
The attached patch adds polled io methods for the mxcuart. I needed them in
order to use kgdb during the early boot. The changes have been sitting in (my
and) Genesi's tree for quite some time now. I believe that the changes are
generally useful and would like you to consider merging them in the "upstream"
repository.
Thanks.
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-09-15 2:03 Jongpill Lee
0 siblings, 0 replies; 88+ messages in thread
From: Jongpill Lee @ 2011-09-15 2:03 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-07-21 11:12 Padmavathi Venna
0 siblings, 0 replies; 88+ messages in thread
From: Padmavathi Venna @ 2011-07-21 11:12 UTC (permalink / raw)
To: linux-arm-kernel
Add external interrupt support for S5P64X0.The external interrupt
group 0(0 to 15) is used for wake-up source in stop and sleep mode.
Add generic irq chip support
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
Please ignore my previous patch due to wrong return value.
arch/arm/mach-s5p64x0/Makefile | 2 +-
arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 10 ++
arch/arm/mach-s5p64x0/irq-eint.c | 152 ++++++++++++++++++++++++
3 files changed, 163 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5p64x0/irq-eint.c
diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
index ae6bf6f..5f6afdf 100644
--- a/arch/arm/mach-s5p64x0/Makefile
+++ b/arch/arm/mach-s5p64x0/Makefile
@@ -13,7 +13,7 @@ obj- :=
# Core support for S5P64X0 system
obj-$(CONFIG_ARCH_S5P64X0) += cpu.o init.o clock.o dma.o gpiolib.o
-obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o
+obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o irq-eint.o
obj-$(CONFIG_CPU_S5P6440) += clock-s5p6440.o
obj-$(CONFIG_CPU_S5P6450) += clock-s5p6450.o
diff --git a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
index 0953ef6..6ce2547 100644
--- a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
+++ b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
@@ -34,4 +34,14 @@
#define S5P6450_GPQ_BASE (S5P_VA_GPIO + 0x0180)
#define S5P6450_GPS_BASE (S5P_VA_GPIO + 0x0300)
+/* External interrupt control registers for group0 */
+
+#define EINT0CON0_OFFSET (0x900)
+#define EINT0MASK_OFFSET (0x920)
+#define EINT0PEND_OFFSET (0x924)
+
+#define S5P64X0_EINT0CON0 (S5P_VA_GPIO + EINT0CON0_OFFSET)
+#define S5P64X0_EINT0MASK (S5P_VA_GPIO + EINT0MASK_OFFSET)
+#define S5P64X0_EINT0PEND (S5P_VA_GPIO + EINT0PEND_OFFSET)
+
#endif /* __ASM_ARCH_REGS_GPIO_H */
diff --git a/arch/arm/mach-s5p64x0/irq-eint.c b/arch/arm/mach-s5p64x0/irq-eint.c
new file mode 100644
index 0000000..69ed454
--- /dev/null
+++ b/arch/arm/mach-s5p64x0/irq-eint.c
@@ -0,0 +1,152 @@
+/* arch/arm/mach-s5p64x0/irq-eint.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd
+ * http://www.samsung.com/
+ *
+ * Based on linux/arch/arm/mach-s3c64xx/irq-eint.c
+ *
+ * S5P64X0 - Interrupt handling for External Interrupts.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+
+#include <plat/regs-irqtype.h>
+#include <plat/gpio-cfg.h>
+
+#include <mach/regs-gpio.h>
+#include <mach/regs-clock.h>
+
+#define eint_offset(irq) ((irq) - IRQ_EINT(0))
+
+static int s5p64x0_irq_eint_set_type(struct irq_data *data, unsigned int type)
+{
+ int offs = eint_offset(data->irq);
+ int shift;
+ u32 ctrl, mask;
+ u32 newvalue = 0;
+
+ if (offs > 15)
+ return -EINVAL;
+
+ switch (type) {
+ case IRQ_TYPE_NONE:
+ printk(KERN_WARNING "No edge setting!\n");
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ newvalue = S3C2410_EXTINT_RISEEDGE;
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ newvalue = S3C2410_EXTINT_FALLEDGE;
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ newvalue = S3C2410_EXTINT_BOTHEDGE;
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ newvalue = S3C2410_EXTINT_LOWLEV;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ newvalue = S3C2410_EXTINT_HILEV;
+ break;
+ default:
+ printk(KERN_ERR "No such irq type %d", type);
+ return -EINVAL;
+ }
+
+ shift = (offs / 2) * 4;
+ mask = 0x7 << shift;
+
+ ctrl = __raw_readl(S5P64X0_EINT0CON0) & ~mask;
+ ctrl |= newvalue << shift;
+ __raw_writel(ctrl, S5P64X0_EINT0CON0);
+
+ /* Configure the GPIO pin for 6450 or 6440 based on CPU ID */
+ if (0x50000 == (__raw_readl(S5P64X0_SYS_ID) & 0xFF000))
+ s3c_gpio_cfgpin(S5P6450_GPN(offs), S3C_GPIO_SFN(2));
+ else
+ s3c_gpio_cfgpin(S5P6440_GPN(offs), S3C_GPIO_SFN(2));
+
+ return 0;
+}
+
+/*
+ * s5p64x0_irq_demux_eint
+ *
+ * This function demuxes the IRQ from the group0 external interrupts,
+ * from IRQ_EINT(0) to IRQ_EINT(15). It is designed to be inlined into
+ * the specific handlers s5p64x0_irq_demux_eintX_Y.
+ */
+static inline void s5p64x0_irq_demux_eint(unsigned int start, unsigned int end)
+{
+ u32 status = __raw_readl(S5P64X0_EINT0PEND);
+ u32 mask = __raw_readl(S5P64X0_EINT0MASK);
+ unsigned int irq;
+
+ status &= ~mask;
+ status >>= start;
+ status &= (1 << (end - start + 1)) - 1;
+
+ for (irq = IRQ_EINT(start); irq <= IRQ_EINT(end); irq++) {
+ if (status & 1)
+ generic_handle_irq(irq);
+ status >>= 1;
+ }
+}
+
+static void s5p64x0_irq_demux_eint0_3(unsigned int irq, struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(0, 3);
+}
+
+static void s5p64x0_irq_demux_eint4_11(unsigned int irq, struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(4, 11);
+}
+
+static void s5p64x0_irq_demux_eint12_15(unsigned int irq,
+ struct irq_desc *desc)
+{
+ s5p64x0_irq_demux_eint(12, 15);
+}
+
+static int s5p64x0_alloc_gc(void)
+{
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+
+ gc = irq_alloc_generic_chip("s5p64x0-eint", 1, S5P_IRQ_EINT_BASE,
+ S5P_VA_GPIO, handle_level_irq);
+ if (!gc) {
+ printk(KERN_ERR "%s: irq_alloc_generic_chip for group 0"
+ "external interrupts failed\n", __func__);
+ return -EINVAL;
+ }
+
+ ct = gc->chip_types;
+ ct->chip.irq_ack = irq_gc_ack;
+ ct->chip.irq_mask = irq_gc_mask_set_bit;
+ ct->chip.irq_unmask = irq_gc_mask_clr_bit;
+ ct->chip.irq_set_type = s5p64x0_irq_eint_set_type;
+ ct->regs.ack = EINT0PEND_OFFSET;
+ ct->regs.mask = EINT0MASK_OFFSET;
+ irq_setup_generic_chip(gc, IRQ_MSK(16), IRQ_GC_INIT_MASK_CACHE,
+ IRQ_NOREQUEST | IRQ_NOPROBE, 0);
+ return 0;
+}
+
+static int __init s5p64x0_init_irq_eint(void)
+{
+ int ret = s5p64x0_alloc_gc();
+ irq_set_chained_handler(IRQ_EINT0_3, s5p64x0_irq_demux_eint0_3);
+ irq_set_chained_handler(IRQ_EINT4_11, s5p64x0_irq_demux_eint4_11);
+ irq_set_chained_handler(IRQ_EINT12_15, s5p64x0_irq_demux_eint12_15);
+
+ return ret;
+}
+arch_initcall(s5p64x0_init_irq_eint);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
@ 2011-06-27 20:47 John Ogness
0 siblings, 0 replies; 88+ messages in thread
From: John Ogness @ 2011-06-27 20:47 UTC (permalink / raw)
To: linux-arm-kernel
The alignment exception handler is setup fairly late in
the boot process (fs_initcall). However, with newer gcc
versions and the compiler option -fconserve-stack, code
accessing unaligned data is generated in functions that
are called earlier, for example pcpu_dump_alloc_info().
This results in unhandled alignment exceptions during
boot. By setting up the exception handler sooner, we
reduce the window where a compiler may generate code
accessing unaligned data.
Here is a minimal example that shows the issue seen with
pcpu_dump_alloc_info():
=========== begin align_test.c ==========
extern void exfunc(char *str);
void somefunc(void)
{
char mystr[] = "--------"; /* 9 bytes */
exfunc(mystr);
}
============ end align_test.c ===========
Using the cross toolchain:
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2011.03-41) 4.5.2
$ arm-none-linux-gnueabi-gcc \
-march=armv6 \
-mtune=arm1136j-s \
-marm \
-Os \
-fconserve-stack \
-c align_test.c
The object dump of align_test.o shows:
00000000 <somefunc>:
0: e92d401f push {r0, r1, r2, r3, r4, lr}
4: e28d0007 add r0, sp, #7
8: e59f3020 ldr r3, [pc, #32] ; 30 <somefunc+0x30>
c: e5932000 ldr r2, [r3]
10: e58d2007 str r2, [sp, #7]
...
...
At address 0x10 there is unaligned access.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
Patch against linux-next-20110831.
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 2 ++
arch/arm/mm/alignment.c | 10 +++++++---
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index a3ca303..b3e18f8 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -232,6 +232,7 @@ extern struct meminfo meminfo;
extern int arm_add_memory(phys_addr_t start, unsigned long size);
extern void early_print(const char *str, ...);
extern void dump_machine_table(void);
+extern int __init alignment_init(void);
#endif /* __KERNEL__ */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 0ca06f7..0f1b2b5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -950,6 +950,8 @@ void __init setup_arch(char **cmdline_p)
#endif
early_trap_init();
+ alignment_init();
+
if (mdesc->init_early)
mdesc->init_early();
}
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 715eb1d..5f013cb 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -950,7 +950,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
* it isn't a sysctl, and it doesn't contain sysctl information.
* We now locate it in /proc/cpu/alignment instead.
*/
-static int __init alignment_init(void)
+static int __init alignment_sysfs_init(void)
{
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *res;
@@ -960,7 +960,13 @@ static int __init alignment_init(void)
if (!res)
return -ENOMEM;
#endif
+ return 0;
+}
+
+fs_initcall(alignment_sysfs_init);
+int __init alignment_init(void)
+{
if (cpu_is_v6_unaligned()) {
cr_alignment &= ~CR_A;
cr_no_alignment &= ~CR_A;
@@ -985,5 +991,3 @@ static int __init alignment_init(void)
return 0;
}
-
-fs_initcall(alignment_init);
--
1.7.2.5
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
@ 2011-06-27 20:47 Jongpill Lee
0 siblings, 0 replies; 88+ messages in thread
From: Jongpill Lee @ 2011-06-27 20:47 UTC (permalink / raw)
To: linux-arm-kernel
>From bogus@does.not.exist.com Mon Jun 27 16:47:34 2011
From: bogus@does.not.exist.com ()
Date: Mon, 27 Jun 2011 20:47:34 -0000
Subject: No subject
Message-ID: <mailman.139.1316181028.20020.linux-arm-kernel@lists.infradead.org>
- General tidy-up after Thomas' review. I've kept the config option
for the time being until we can sort out the anonymous union
problem.
Marc Zyngier (3):
genirq: add support for per-cpu dev_id interrupts
ARM: gic: consolidate PPI handling
ARM: gic, local timers: use the request_percpu_irq() interface
arch/arm/common/Kconfig | 1 +
arch/arm/common/gic.c | 38 +++-
arch/arm/include/asm/entry-macro-multi.S | 7 -
arch/arm/include/asm/hardirq.h | 3 -
arch/arm/include/asm/hardware/entry-macro-gic.S | 19 +--
arch/arm/include/asm/hardware/gic.h | 1 -
arch/arm/include/asm/localtimer.h | 19 +-
arch/arm/include/asm/smp.h | 5 -
arch/arm/include/asm/smp_twd.h | 2 +-
arch/arm/kernel/irq.c | 3 -
arch/arm/kernel/smp.c | 33 +---
arch/arm/kernel/smp_twd.c | 47 +++++-
arch/arm/mach-exynos4/include/mach/entry-macro.S | 6 +-
arch/arm/mach-exynos4/mct.c | 5 -
arch/arm/mach-msm/board-msm8x60.c | 11 -
arch/arm/mach-msm/include/mach/entry-macro-qgic.S | 73 +-------
arch/arm/mach-msm/timer.c | 69 ++++---
arch/arm/mach-omap2/include/mach/entry-macro.S | 14 +--
arch/arm/mach-shmobile/entry-intc.S | 3 -
arch/arm/mach-shmobile/include/mach/entry-macro.S | 3 -
include/linux/interrupt.h | 40 +++-
include/linux/irq.h | 16 ++-
include/linux/irqdesc.h | 1 +
kernel/irq/Kconfig | 4 +
kernel/irq/chip.c | 54 ++++++
kernel/irq/internals.h | 2 +
kernel/irq/irqdesc.c | 25 +++
kernel/irq/manage.c | 209 +++++++++++++++++=
+++-
kernel/irq/settings.h | 7 +
29 files changed, 471 insertions(+), 249 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-06-13 17:29 Andre Silva
0 siblings, 0 replies; 88+ messages in thread
From: Andre Silva @ 2011-06-13 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH 1/2] ARM:mach-mx5/mx53_ard: Add ESDHC support
Signed-off-by: Andre Silva <andre.silva@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_ard.c | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 695cdf0..9a8e6f8 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -213,6 +213,7 @@ config MACH_MX53_ARD
bool "Support MX53 ARD platforms"
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
help
Include support for MX53 ARD platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_ard.c b/arch/arm/mach-mx5/board-mx53_ard.c
index 7e1859b..6049fda 100644
--- a/arch/arm/mach-mx5/board-mx53_ard.c
+++ b/arch/arm/mach-mx5/board-mx53_ard.c
@@ -36,6 +36,8 @@
#include "devices-imx53.h"
#define ARD_ETHERNET_INT_B IMX_GPIO_NR(2, 31)
+#define ARD_SD1_CD IMX_GPIO_NR(1, 1)
+#define ARD_SD1_WP IMX_GPIO_NR(1, 9)
static iomux_v3_cfg_t mx53_ard_pads[] = {
/* UART1 */
@@ -69,6 +71,19 @@ static iomux_v3_cfg_t mx53_ard_pads[] = {
MX53_PAD_EIM_OE__EMI_WEIM_OE,
MX53_PAD_EIM_RW__EMI_WEIM_RW,
MX53_PAD_EIM_CS1__EMI_WEIM_CS_1,
+ /* SDHC1 */
+ MX53_PAD_SD1_CMD__ESDHC1_CMD,
+ MX53_PAD_SD1_CLK__ESDHC1_CLK,
+ MX53_PAD_SD1_DATA0__ESDHC1_DAT0,
+ MX53_PAD_SD1_DATA1__ESDHC1_DAT1,
+ MX53_PAD_SD1_DATA2__ESDHC1_DAT2,
+ MX53_PAD_SD1_DATA3__ESDHC1_DAT3,
+ MX53_PAD_PATA_DATA8__ESDHC1_DAT4,
+ MX53_PAD_PATA_DATA9__ESDHC1_DAT5,
+ MX53_PAD_PATA_DATA10__ESDHC1_DAT6,
+ MX53_PAD_PATA_DATA11__ESDHC1_DAT7,
+ MX53_PAD_GPIO_1__GPIO1_1,
+ MX53_PAD_GPIO_9__GPIO1_9,
};
static struct resource ard_smsc911x_resources[] = {
@@ -100,6 +115,11 @@ static struct platform_device ard_smsc_lan9220_device = {
},
};
+static const struct esdhc_platform_data mx53_ard_sd1_data __initconst = {
+ .cd_gpio = ARD_SD1_CD,
+ .wp_gpio = ARD_SD1_WP,
+};
+
static void __init mx53_ard_io_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_ard_pads,
@@ -156,6 +176,8 @@ static void __init mx53_ard_board_init(void)
mx53_ard_io_init();
weim_cs_config();
platform_add_devices(devices, ARRAY_SIZE(devices));
+
+ imx53_add_sdhci_esdhc_imx(0, &mx53_ard_sd1_data);
}
static void __init mx53_ard_timer_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
@ 2011-06-05 18:33 Hector Oron
0 siblings, 0 replies; 88+ messages in thread
From: Hector Oron @ 2011-06-05 18:33 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-05-17 9:28 Javier Martin
0 siblings, 0 replies; 88+ messages in thread
From: Javier Martin @ 2011-05-17 9:28 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches provides support for Aptina mt9p031 sensor on Beagleboard xM.
It has been tested using media-ctl and yavta.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-05-13 19:35 Vadim Bendebury
0 siblings, 0 replies; 88+ messages in thread
From: Vadim Bendebury @ 2011-05-13 19:35 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-03-01 14:02 Javier Martin
0 siblings, 0 replies; 88+ messages in thread
From: Javier Martin @ 2011-03-01 14:02 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches provides support for audio in Visstrim_M10 boards.
This second version has some fixes in the aic32x4 codec driver as asked by
Mark Brown.
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2011-01-13 9:13 Uwe Kleine-König
0 siblings, 0 replies; 88+ messages in thread
From: Uwe Kleine-König @ 2011-01-13 9:13 UTC (permalink / raw)
To: linux-arm-kernel
<jason77.wang@gmail.com>
Bcc:
Subject: Re: i.MX & IRQF_ONESHOT
Reply-To:
In-Reply-To: <4D2EB6EF.7030608@eukrea.com>
Hello,
[adding tglx who AFAIK invented threaded irqs and the people involved
in 2991a1ca6e9b to Cc]
On Thu, Jan 13, 2011 at 09:25:19AM +0100, Eric B?nard wrote:
> while testing 2.6.37 on our i.MX27 based board - code in
> arch/arm/mach-imx/eukrea_mbimx27-baseboard.c - I noticed the
> touchscreen controller (ADS7846) doesn't work anymore.
>
> A few IRQ are generated when probing for the chipset and starting
> calibration (usually first point works), then nothing more (even if
> the IRQ signals is generated as seen on the scope, the irq count
> doesn't increase anymore and stays <= 4 and no data is reported to
> the input layer).
>
> drivers/input/touchscreen/ads7846.c was switched to threaded IRQ in
> commit 2991a1ca6e9b13b639a82c0eec0cbc191bf1f42f where was added :
> irq_flags |= IRQF_ONESHOT;
AFAIK this is how threaded irq usually work. The irq should get
reenabled by irq_thread -> irq_finalize_oneshot then.
> Commenting out this line in the ads7846 driver makes it work again.
> Am I missing something obvious or is there a reason for IRQF_ONESHOT
> creating trouble with gpio irq or SPI on i.MX ?
I don't know. Is the irq masked? pending?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-12-03 1:08 tarek attia
0 siblings, 0 replies; 88+ messages in thread
From: tarek attia @ 2010-12-03 1:08 UTC (permalink / raw)
To: linux-arm-kernel
register
--
tarek
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-10-08 6:02 Daein Moon
0 siblings, 0 replies; 88+ messages in thread
From: Daein Moon @ 2010-10-08 6:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben Dooks and Kukjin,
I found an issue about s3c_gpio_getpull API.
The 'plat-samsung' provides 's3c_gpio_setpull' and 's3c_gpio_getpull'
to set and get pull-{none|up|down} of GPIO. But there is no
's3c_gpio_getpull' definition in 'arch/arm/plat-samsung/gpio-config.c',
and there is only declaration in the corresponding header file.
's3c_gpio_getpull' isn't supported/used. So if providing this api, its
definition should be inserted.
Otherwise, code that is used to provide s3c_gpio_getpull including
following code should be removed.
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
extern s3c_gpio_pull_t s3c_gpio_getpull(unsigned int pin);
arch/arm/mach-{s3c*|s5p*}/gpiolib.c:
.get_pull = s3c_gpio_getpull_updown,
What do you think about that?
Best Regards,
Daein Moon
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-09-09 3:33 tarek attia
0 siblings, 0 replies; 88+ messages in thread
From: tarek attia @ 2010-09-09 3:33 UTC (permalink / raw)
To: linux-arm-kernel
register
--
tarek
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-06-24 13:48 Uwe Kleine-König
0 siblings, 0 replies; 88+ messages in thread
From: Uwe Kleine-König @ 2010-06-24 13:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this is the next step in the project "clean up the imx port" targeting
2.6.36. The highlights this time are:
- Unification of mach-mx2 and mach-mx1 into mach-imx
- start allocating devices dynamically
This should reduce the memory footprint because (in the end) no
unused struct platform_device, struct resource or struct
$platformdatafordriverX are kept in memory. This also cleans up
with naming conflicts.
This is intermixed with various fixes and simplifications.
I have to admit that some patches could have squashed but squashing them
now would be more work that it's worth so I kept them as they are now.
The patches are based on 67a3e12b05e055c0415c556a315a3d3eb637e29e
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
and are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git imx/for-2.6.36
plus sent as a reply to this mail. Shortlog and diffstat are to be
found below.
Have fun
Uwe
Uwe Kleine-K?nig (61):
ARM: mx3: rename mach-mx35pdk.c to mach-mx35_3ds.c matching its arch number
ARM: mx25: rename mach-mx25pdk.c to mach-mx25_3ds.c matching its arch number
ARM: mx1: don't use deprecated symbol names
ARM: mx1/scb9328: fix type of uart1_mxc_exit to make compiler happy
ARM: mx2/mx27_3ds: document alternative names and remove empty header
ARM: imx: remove empty and unused board headers
ARM: mx3/kzm_arm11_01: fold board header in its only user
ARM: mx2/mx21ads: fold board header in its only user
ARM: mx2/mx27ads: fold board header in its only user
ARM: mx3/qong: get rid of nearly empty header
ARM: mx3/mx31_3ds: fold board header in its only user
ARM: mx3/mx31ads: fold board header in its only user
ARM: mxc: grammar fix
ARM: imx: rename mach dir for mx21 and mx27 to mach-imx
ARM: imx/mx1: fold crm_regs.h into its only consumer
ARM: imx: get rid of mxc_gpio_init
ARM: imx: fold serial.c into devices.c
ARM: imx1: rename imx_csi_device to match its .name
ARM: imx1: rename imx_i2c_device to follow a common naming scheme
ARM: imx1: rename imx_uart[12]_device to follow a common naming scheme
ARM: mx3: mx31lilly: fix build error for !CONFIG_USB_ULPI
ARM: imx: rename mxc_uart_devicex to follow a common naming scheme
ARM: imx: move mx1 support to mach-imx
ARM: imx: Kconfig: use an if block instead of a depend for many symbols
ARM: imx: prepare deprecating ARCH_MX1, MACH_MX2, MACH_MX21 and MACH_MX27
ARM: imx: prepare deprecating ARCH_MX1, MACH_MX2, MACH_MX21 and MACH_MX27
ARM: imx: new Kconfig symbol and feature test macro for DMA on mx1 and mx2
ARM: imx: new helper function imx_add_platform_device
MTD: mxc_nand: make bit fields unsigned to please sparse
ARM: imx: remove paragraphs with old address of the FSF
ARM: mx25: remove paragraphs with old address of the FSF
ARM: mx3: remove paragraphs with old address of the FSF
ARM: mxc91231: remove paragraphs with old address of the FSF
ARM: mxc: remove paragraphs with old address of the FSF
ARM: imx: Change the way nand devices are registered (generic part)
ARM: imx: Change the way nand devices are registered (imx21)
ARM: imx: Change the way nand devices are registered (imx25)
ARM: imx: Change the way nand devices are registered (imx27)
ARM: imx: Change the way nand devices are registered (imx31)
ARM: imx: Change the way nand devices are registered (imx35)
ARM: imx: dynamically register imx-i2c devices (generic part)
ARM: imx: dynamically register imx-i2c devices (imx1)
ARM: imx: dynamically register imx-i2c devices (imx21)
ARM: imx: dynamically register imx-i2c devices (imx25)
ARM: imx: dynamically register imx-i2c devices (imx27)
ARM: imx: dynamically register imx-i2c devices (imx31)
ARM: imx: dynamically register imx-i2c devices (imx35)
ARM: imx: dynamically register spi_imx devices (generic part)
ARM: imx: dynamically register spi_imx devices (imx21)
ARM: imx: dynamically register spi_imx devices (imx25)
ARM: imx: dynamically register spi_imx devices (imx27)
ARM: imx: dynamically register spi_imx devices (imx31)
ARM: imx: dynamically register spi_imx devices (imx35)
ARM: imx: dynamically register imx-uart devices (generic part)
ARM: imx: dynamically register imx-uart devices (imx1)
ARM: imx: dynamically register imx-uart devices (imx21)
ARM: imx: dynamically register imx-uart devices (imx25)
ARM: imx: dynamically register imx-uart devices (imx27)
ARM: imx: dynamically register imx-uart devices (imx31)
ARM: imx: dynamically register imx-uart devices (imx35)
ARM: mx3: complement uart init routine with an exit routine
arch/arm/Makefile | 4 +-
arch/arm/mach-imx/Kconfig | 186 +++++++++++
arch/arm/{mach-mx2 => mach-imx}/Makefile | 18 +-
arch/arm/{mach-mx2 => mach-imx}/Makefile.boot | 4 +
.../{mach-mx1/clock.c => mach-imx/clock-imx1.c} | 50 +++-
.../clock_imx21.c => mach-imx/clock-imx21.c} | 0
.../clock_imx27.c => mach-imx/clock-imx27.c} | 0
.../{mach-mx2/cpu_imx27.c => mach-imx/cpu-imx27.c} | 0
arch/arm/mach-imx/devices-imx1.h | 18 +
arch/arm/mach-imx/devices-imx21.h | 30 ++
arch/arm/mach-imx/devices-imx27.h | 38 +++
arch/arm/{mach-mx2 => mach-imx}/devices.c | 250 +++++++++------
arch/arm/{mach-mx2 => mach-imx}/devices.h | 30 +--
.../{plat-mxc/dma-mx1-mx2.c => mach-imx/dma-v1.c} | 4 +-
.../eukrea_mbimx27-baseboard.c | 19 +-
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h | 10 +
.../include/mach/dma-v1.h} | 10 +-
arch/arm/{mach-mx2 => mach-imx}/mach-cpuimx27.c | 25 +-
arch/arm/{mach-mx2 => mach-imx}/mach-imx27lite.c | 11 +-
arch/arm/{mach-mx1 => mach-imx}/mach-mx1ads.c | 34 +-
arch/arm/{mach-mx2 => mach-imx}/mach-mx21ads.c | 58 +++-
arch/arm/{mach-mx2 => mach-imx}/mach-mx27_3ds.c | 17 +-
arch/arm/{mach-mx2 => mach-imx}/mach-mx27ads.c | 76 +++--
arch/arm/{mach-mx2 => mach-imx}/mach-mxt_td60.c | 36 +--
arch/arm/{mach-mx2 => mach-imx}/mach-pca100.c | 23 +-
arch/arm/{mach-mx2 => mach-imx}/mach-pcm038.c | 33 +--
arch/arm/{mach-mx1 => mach-imx}/mach-scb9328.c | 21 +-
.../arm/{mach-mx1/generic.c => mach-imx/mm-imx1.c} | 23 +-
arch/arm/{mach-mx2 => mach-imx}/mm-imx21.c | 5 +-
arch/arm/{mach-mx2 => mach-imx}/mm-imx27.c | 5 +-
.../ksym_mx1.c => mach-imx/mx1-camera-fiq-ksym.c} | 0
.../mx1_camera_fiq.S => mach-imx/mx1-camera-fiq.S} | 0
arch/arm/{mach-mx2 => mach-imx}/pcm970-baseboard.c | 0
arch/arm/mach-mx1/Kconfig | 19 -
arch/arm/mach-mx1/Makefile | 15 -
arch/arm/mach-mx1/Makefile.boot | 4 -
arch/arm/mach-mx1/crm_regs.h | 55 ---
arch/arm/mach-mx1/devices.c | 242 --------------
arch/arm/mach-mx1/devices.h | 7 -
arch/arm/mach-mx2/Kconfig | 116 -------
arch/arm/mach-mx2/serial.c | 141 --------
arch/arm/mach-mx25/Kconfig | 2 +
arch/arm/mach-mx25/Makefile | 2 +-
arch/arm/mach-mx25/devices-imx25.h | 38 +++
arch/arm/mach-mx25/devices.c | 231 +-------------
arch/arm/mach-mx25/devices.h | 12 -
.../mach-mx25/{mach-mx25pdk.c => mach-mx25_3ds.c} | 21 +-
arch/arm/mach-mx25/mm.c | 7 +-
arch/arm/mach-mx3/Kconfig | 26 ++
arch/arm/mach-mx3/Makefile | 2 +-
arch/arm/mach-mx3/devices-imx31.h | 38 +++
arch/arm/mach-mx3/devices-imx35.h | 32 ++
arch/arm/mach-mx3/devices.c | 247 +--------------
arch/arm/mach-mx3/devices.h | 13 -
arch/arm/mach-mx3/mach-armadillo5x0.c | 17 +-
arch/arm/mach-mx3/mach-kzm_arm11_01.c | 31 ++-
arch/arm/mach-mx3/mach-mx31_3ds.c | 64 +++--
arch/arm/mach-mx3/mach-mx31ads.c | 55 +++-
arch/arm/mach-mx3/mach-mx31lilly.c | 47 ++--
arch/arm/mach-mx3/mach-mx31lite.c | 17 +-
arch/arm/mach-mx3/mach-mx31moboard.c | 50 ++--
.../mach-mx3/{mach-mx35pdk.c => mach-mx35_3ds.c} | 16 +-
arch/arm/mach-mx3/mach-pcm037.c | 31 +-
arch/arm/mach-mx3/mach-pcm037_eet.c | 7 +-
arch/arm/mach-mx3/mach-pcm043.c | 25 +-
arch/arm/mach-mx3/mach-qong.c | 16 +-
arch/arm/mach-mx3/mm.c | 7 +-
arch/arm/mach-mx3/mx31lilly-db.c | 14 +-
arch/arm/mach-mx3/mx31lite-db.c | 15 +-
arch/arm/mach-mx3/mx31moboard-devboard.c | 10 +-
arch/arm/mach-mx3/mx31moboard-marxbot.c | 4 -
arch/arm/mach-mx3/mx31moboard-smartbot.c | 11 +-
arch/arm/mach-mx5/devices.c | 2 +-
arch/arm/mach-mx5/mm.c | 3 +
arch/arm/mach-mxc91231/crm_regs.h | 5 -
arch/arm/mach-mxc91231/devices.c | 2 +-
arch/arm/mach-mxc91231/mm.c | 8 +-
arch/arm/plat-mxc/Kconfig | 10 +-
arch/arm/plat-mxc/Makefile | 4 +-
arch/arm/plat-mxc/audmux-v1.c | 4 -
arch/arm/plat-mxc/audmux-v2.c | 4 -
arch/arm/plat-mxc/devices.c | 33 ++
arch/arm/plat-mxc/devices/Kconfig | 11 +
arch/arm/plat-mxc/devices/Makefile | 4 +
arch/arm/plat-mxc/devices/platform-imx-i2c.c | 29 ++
arch/arm/plat-mxc/devices/platform-imx-uart.c | 60 ++++
arch/arm/plat-mxc/devices/platform-mxc_nand.c | 44 +++
arch/arm/plat-mxc/devices/platform-spi_imx.c | 30 ++
arch/arm/plat-mxc/ehci.c | 4 -
.../arm/plat-mxc/include/mach/board-armadillo5x0.h | 15 -
.../plat-mxc/include/mach/board-eukrea_cpuimx27.h | 2 +-
arch/arm/plat-mxc/include/mach/board-kzmarm11.h | 39 ---
arch/arm/plat-mxc/include/mach/board-mx21ads.h | 52 ---
arch/arm/plat-mxc/include/mach/board-mx27ads.h | 344 --------------------
arch/arm/plat-mxc/include/mach/board-mx27lite.h | 14 -
arch/arm/plat-mxc/include/mach/board-mx27pdk.h | 14 -
arch/arm/plat-mxc/include/mach/board-mx31_3ds.h | 59 ----
arch/arm/plat-mxc/include/mach/board-mx31ads.h | 117 -------
arch/arm/plat-mxc/include/mach/board-mx31lilly.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx31lite.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx31moboard.h | 2 +-
arch/arm/plat-mxc/include/mach/board-mx35pdk.h | 22 --
arch/arm/plat-mxc/include/mach/board-pcm037.h | 22 --
arch/arm/plat-mxc/include/mach/board-pcm038.h | 2 +-
arch/arm/plat-mxc/include/mach/board-pcm043.h | 22 --
arch/arm/plat-mxc/include/mach/board-qong.h | 17 -
arch/arm/plat-mxc/include/mach/devices-common.h | 42 +++
arch/arm/plat-mxc/include/mach/iomux-mxc91231.h | 4 -
arch/arm/plat-mxc/include/mach/mx1.h | 28 +-
arch/arm/plat-mxc/include/mach/mx25.h | 28 ++-
arch/arm/plat-mxc/include/mach/mx27.h | 4 +-
arch/arm/plat-mxc/include/mach/mx31.h | 4 +-
arch/arm/plat-mxc/include/mach/mx35.h | 4 +-
arch/arm/plat-mxc/include/mach/mx3_camera.h | 4 -
arch/arm/plat-mxc/include/mach/mxc91231.h | 4 -
arch/arm/plat-mxc/include/mach/mxc_nand.h | 6 +-
arch/arm/plat-mxc/include/mach/system.h | 4 -
arch/arm/plat-mxc/include/mach/timex.h | 4 -
arch/arm/plat-mxc/include/mach/uncompress.h | 4 -
arch/arm/plat-mxc/include/mach/vmalloc.h | 4 -
arch/arm/plat-mxc/irq.c | 3 -
arch/arm/plat-mxc/system.c | 4 -
arch/arm/plat-mxc/tzic.c | 2 -
123 files changed, 1424 insertions(+), 2478 deletions(-)
create mode 100644 arch/arm/mach-imx/Kconfig
rename arch/arm/{mach-mx2 => mach-imx}/Makefile (55%)
rename arch/arm/{mach-mx2 => mach-imx}/Makefile.boot (67%)
rename arch/arm/{mach-mx1/clock.c => mach-imx/clock-imx1.c} (90%)
rename arch/arm/{mach-mx2/clock_imx21.c => mach-imx/clock-imx21.c} (100%)
rename arch/arm/{mach-mx2/clock_imx27.c => mach-imx/clock-imx27.c} (100%)
rename arch/arm/{mach-mx2/cpu_imx27.c => mach-imx/cpu-imx27.c} (100%)
create mode 100644 arch/arm/mach-imx/devices-imx1.h
create mode 100644 arch/arm/mach-imx/devices-imx21.h
create mode 100644 arch/arm/mach-imx/devices-imx27.h
rename arch/arm/{mach-mx2 => mach-imx}/devices.c (73%)
rename arch/arm/{mach-mx2 => mach-imx}/devices.h (54%)
rename arch/arm/{plat-mxc/dma-mx1-mx2.c => mach-imx/dma-v1.c} (99%)
rename arch/arm/{mach-mx2 => mach-imx}/eukrea_mbimx27-baseboard.c (93%)
create mode 100644 arch/arm/mach-imx/include/mach/dma-mx1-mx2.h
rename arch/arm/{plat-mxc/include/mach/dma-mx1-mx2.h => mach-imx/include/mach/dma-v1.h} (93%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-cpuimx27.c (90%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-imx27lite.c (86%)
rename arch/arm/{mach-mx1 => mach-imx}/mach-mx1ads.c (81%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx21ads.c (77%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx27_3ds.c (85%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mx27ads.c (82%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-mxt_td60.c (86%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-pca100.c (93%)
rename arch/arm/{mach-mx2 => mach-imx}/mach-pcm038.c (91%)
rename arch/arm/{mach-mx1 => mach-imx}/mach-scb9328.c (89%)
rename arch/arm/{mach-mx1/generic.c => mach-imx/mm-imx1.c} (68%)
rename arch/arm/{mach-mx2 => mach-imx}/mm-imx21.c (95%)
rename arch/arm/{mach-mx2 => mach-imx}/mm-imx27.c (95%)
rename arch/arm/{mach-mx1/ksym_mx1.c => mach-imx/mx1-camera-fiq-ksym.c} (100%)
rename arch/arm/{mach-mx1/mx1_camera_fiq.S => mach-imx/mx1-camera-fiq.S} (100%)
rename arch/arm/{mach-mx2 => mach-imx}/pcm970-baseboard.c (100%)
delete mode 100644 arch/arm/mach-mx1/Kconfig
delete mode 100644 arch/arm/mach-mx1/Makefile
delete mode 100644 arch/arm/mach-mx1/Makefile.boot
delete mode 100644 arch/arm/mach-mx1/crm_regs.h
delete mode 100644 arch/arm/mach-mx1/devices.c
delete mode 100644 arch/arm/mach-mx1/devices.h
delete mode 100644 arch/arm/mach-mx2/Kconfig
delete mode 100644 arch/arm/mach-mx2/serial.c
create mode 100644 arch/arm/mach-mx25/devices-imx25.h
rename arch/arm/mach-mx25/{mach-mx25pdk.c => mach-mx25_3ds.c} (91%)
create mode 100644 arch/arm/mach-mx3/devices-imx31.h
create mode 100644 arch/arm/mach-mx3/devices-imx35.h
rename arch/arm/mach-mx3/{mach-mx35pdk.c => mach-mx35_3ds.c} (89%)
create mode 100644 arch/arm/plat-mxc/devices/Kconfig
create mode 100644 arch/arm/plat-mxc/devices/Makefile
create mode 100644 arch/arm/plat-mxc/devices/platform-imx-i2c.c
create mode 100644 arch/arm/plat-mxc/devices/platform-imx-uart.c
create mode 100644 arch/arm/plat-mxc/devices/platform-mxc_nand.c
create mode 100644 arch/arm/plat-mxc/devices/platform-spi_imx.c
delete mode 100644 arch/arm/plat-mxc/include/mach/board-armadillo5x0.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-kzmarm11.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx21ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27lite.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx27pdk.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx31_3ds.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx31ads.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-mx35pdk.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-pcm037.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-pcm043.h
delete mode 100644 arch/arm/plat-mxc/include/mach/board-qong.h
create mode 100644 arch/arm/plat-mxc/include/mach/devices-common.h
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-06-07 17:58 Dave Hylands
0 siblings, 0 replies; 88+ messages in thread
From: Dave Hylands @ 2010-06-07 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I'm trying to understand what I need to be concerned about with SMP
processors and sharing global data (in particular a dual Cortex-A9)
I'm familiar with spinlocks, but in this case I'm trying to work with
some lockless data structures.
What I'm not sure is whether the following would work. Suppose I have
a couple of 8-bit get/put indicies which are in adjacent memory
locations (within the same 32-bit word).
If I have an ISR and a thread running on an SMP core, and the ISR is
running on one core and the thread is running on a second core, if the
ISR were to only write to the put pointer and the thread were only to
write to the get pointer, does the cache maintain consistency? Or do
the get and put pointers need to be in separate cache lines?
Another way of asking this: If both cores are writing to the same
32-bit word (but different bytes) do the writes collide?
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-05-18 10:38 Marek Szyprowski
0 siblings, 0 replies; 88+ messages in thread
From: Marek Szyprowski @ 2010-05-18 10:38 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series perform a general cleanup in Samsung S5PC100 SoC support.
This chip is moved from custom s5pc1xx platform framework to new plat-s5p
framework, so more common code can be easily reused in upcomming extensions
for S5PV210/S5PC110 SoCs.
This patch series is prepared against next-samsung tree, with assumption
that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
I've tried to split my changes as much as possible to clearly show how the
transition from plat-s5pc1xx to plat-s5p is being done.
Changes since v2:
- fixed some whitespace/tabs errors
- removed external interrupt code, a common code from plat-s5p will be used
- moved SMDKC100 fixes to separate patch series
Changes since v1:
- bases on completely new clock code provided by Kukjin Kim
- added some plat-s5p fixes required for transition
- removed custom functions from gpiolib implementation (now uses common
code from plat-samsung)
- restructured the changes to avoid breaking the functionality beteen the
patches
- some other minor cleanups (mainly c1xx to c100 renames)
This patch series includes:
[PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
[PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
[PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
[PATCH 04/11] ARM: S5PC100: gpio.h cleanup
[PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
[PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
[PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
[PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-04-17 21:43 nelakurthi koteswararao
0 siblings, 0 replies; 88+ messages in thread
From: nelakurthi koteswararao @ 2010-04-17 21:43 UTC (permalink / raw)
To: linux-arm-kernel
http://ColleenKitts2530.co.cc
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2010-02-25 9:36 Thomas Weber
0 siblings, 0 replies; 88+ messages in thread
From: Thomas Weber @ 2010-02-25 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Subject: [PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init
The omap_serial_early_init prints the following errors:
Could not get uart4_ick
Could not get uart4_fck
because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.
Signed-off-by: Thomas Weber <weber@corscience.de>
---
arch/arm/mach-omap2/serial.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..da77930 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -644,16 +644,21 @@ static void serial_out_override(struct uart_port *up, int offset, int value)
}
void __init omap_serial_early_init(void)
{
- int i;
+ int i, nr_ports;
char name[16];
+ if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ nr_ports = 3;
+ else
+ nr_ports = ARRAY_SIZE(omap_uart);
+
/*
* Make sure the serial ports are muxed on at this point.
* You have to mux them off in device drivers later on
* if not needed.
*/
- for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i < nr_ports; i++) {
struct omap_uart_state *uart = &omap_uart[i];
struct platform_device *pdev = &uart->pdev;
struct device *dev = &pdev->dev;
@@ -669,17 +674,17 @@ void __init omap_serial_early_init(void)
continue;
}
- sprintf(name, "uart%d_ick", i+1);
+ sprintf(name, "uart%d_ick", i + 1);
uart->ick = clk_get(NULL, name);
if (IS_ERR(uart->ick)) {
- printk(KERN_ERR "Could not get uart%d_ick\n", i+1);
+ printk(KERN_ERR "Could not get uart%d_ick\n", i + 1);
uart->ick = NULL;
}
sprintf(name, "uart%d_fck", i+1);
uart->fck = clk_get(NULL, name);
if (IS_ERR(uart->fck)) {
- printk(KERN_ERR "Could not get uart%d_fck\n", i+1);
+ printk(KERN_ERR "Could not get uart%d_fck\n", i + 1);
uart->fck = NULL;
}
--
1.6.4.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* No subject
@ 2009-09-17 9:37 Marc Kleine-Budde
0 siblings, 0 replies; 88+ messages in thread
From: Marc Kleine-Budde @ 2009-09-17 9:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patch series adds support for the Atmel CAN controller as found
on the AT91SAM9263.
It adds the at91_can to the generic device definition, activates the CAN
controller on the at91sam9263ek and adds the driver itself.
Changes since V1:
- let Kconfig depend on CAN_DEV
- add example how driver is used in baord file
Please review and consider for inclusion.
cheers, Marc
Marc Kleine-Budde (3):
at91sam9263: add at91_can device to generic device definition
at91sam9263ek: activate at91 CAN controller
at91_can: add driver for Atmel's CAN controller on AT91SAM9263
arch/arm/mach-at91/at91sam9263_devices.c | 36 +
arch/arm/mach-at91/board-sam9263ek.c | 19 +
arch/arm/mach-at91/include/mach/board.h | 6 +
drivers/net/can/Kconfig | 6 +
drivers/net/can/Makefile | 1 +
drivers/net/can/at91_can.c | 1186 ++++++++++++++++++++++++++++++
6 files changed, 1254 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/can/at91_can.c
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2009-09-07 14:07 Somshekar ChandrashekarKadam
0 siblings, 0 replies; 88+ messages in thread
From: Somshekar ChandrashekarKadam @ 2009-09-07 14:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin Marinas,
I am working on ARM1176 Realview board.
Kernel stable arm 2.6.28
My first query
I think reboot command is not implemented. ?
Work done locally here.
Implemented reboot by setting 8th bit of SYS_RESETCTL (reset control register 0x10000040). It works fine when given command reboot.
Issue Faced
ASLA works fine when done hard poweroff and poweron. ALSA detected properly and works fine.When I do a soft reboot using reboot command. when kernel boots up it doesn't detect ALSA device itself with the
following messages. It is not able to read AC97 Register failing
because of timeout. I tried increasing the timeout and udelay still the
same case. Messages are shown below a the end.I also tried setting the various depth of a soft reset like
(1=SYSRST rest logic tile, 2=PLLLOCK reset PLL, 4=PBRESET board reset,
same as pressing reset button). still ALSA does not work.Now I am confused on this. Please throw some light on this or any pointer will be useful.It is not able to read AC97 Register failing
because of timeout. routine (/*
* Read an AC'97 register.
*/
static unsigned short aaci_ac97_read(struct snd_ac97 *ac97, unsigned short reg))
I hope i have made myself clear.
Thanks In Advance
Messages when ALSA not detected
====================================================
When sound doesn't work I see following in boot log:
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 1c)
port 1 high speed
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7c)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 7e)
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back (0 != 1c)
usb 1-1: new high speed USB device using isp1760 and address 2
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: ac97 read back fail. retry
aaci-pl041 fpga:04: wrong ac97 register read back
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20090907/092b9ae9/attachment-0001.htm>
^ permalink raw reply [flat|nested] 88+ messages in thread
* No subject
@ 2009-08-25 10:34 Syed Rafiuddin
0 siblings, 0 replies; 88+ messages in thread
From: Syed Rafiuddin @ 2009-08-25 10:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Syed Rafiuddin <rafiuddin.syed@ti.com>
This patch Adds Keypad support on OMAP4.And adds
OMAP4 register addresses and configures them for OMAP4.
This patch has been updated as per the comments received from
Trilok Soni to remove GPIO based omap2 keypad logic from omap_keypad.c
(http://www.mail-archive.com/linux-omap at vger.kernel.org/msg14570.html)
Matrix_keypad.c (gpio based keypad driver) can be used in OMAP2,
which is not tested on OMAP2 since unavailability of omap2 target's.
Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
---
drivers/input/keyboard/omap-keypad.c | 247 ++++++++++++++++-------------------
1 files changed, 115 insertions(+), 132 deletions(-)
Index: kernel-omap4-base/drivers/input/keyboard/omap-keypad.c
===================================================================
--- kernel-omap4-base.orig/drivers/input/keyboard/omap-keypad.c 2009-08-19 12:23:14.000000000 +0530
+++ kernel-omap4-base/drivers/input/keyboard/omap-keypad.c 2009-08-19 18:25:17.000000000 +0530
@@ -44,6 +44,36 @@
#undef NEW_BOARD_LEARNING_MODE
+#define OMAP4_KBDOCP_BASE 0x4A31C000
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG 0x10
+#define OMAP4_KBD_SYSSTATUS 0x14
+#define OMAP4_KBD_IRQSTATUS 0x18
+#define OMAP4_KBD_IRQENABLE 0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS 0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS 0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_32 0x48
+
+#define OMAP4_KBD_SYSCONFIG_SOFTRST (1 << 1)
+#define OMAP4_KBD_SYSCONFIG_ENAWKUP (1 << 2)
+#define OMAP4_KBD_IRQENABLE_EVENTEN (1 << 0)
+#define OMAP4_KBD_IRQENABLE_LONGKEY (1 << 1)
+#define OMAP4_KBD_IRQENABLE_TIMEOUTEN (1 << 2)
+#define OMAP4_KBD_CTRL_NOSOFTMODE (1 << 1)
+#define OMAP4_KBD_CTRLPTVVALUE (1 << 2)
+#define OMAP4_KBD_CTRLPTV (1 << 1)
+#define OMAP4_KBD_IRQDISABLE 0x00
+
+#define OMAP4_KBD_IRQSTATUSDISABLE 0xffff
+
static void omap_kp_tasklet(unsigned long);
static void omap_kp_timer(unsigned long);
@@ -65,55 +95,16 @@ struct omap_kp {
static DECLARE_TASKLET_DISABLED(kp_tasklet, omap_kp_tasklet, 0);
static int *keymap;
-static unsigned int *row_gpios;
-static unsigned int *col_gpios;
-
-#ifdef CONFIG_ARCH_OMAP2
-static void set_col_gpio_val(struct omap_kp *omap_kp, u8 value)
-{
- int col;
-
- for (col = 0; col < omap_kp->cols; col++)
- gpio_set_value(col_gpios[col], value & (1 << col));
-}
-
-static u8 get_row_gpio_val(struct omap_kp *omap_kp)
-{
- int row;
- u8 value = 0;
-
- for (row = 0; row < omap_kp->rows; row++) {
- if (gpio_get_value(row_gpios[row]))
- value |= (1 << row);
- }
- return value;
-}
-#else
-#define set_col_gpio_val(x, y) do {} while (0)
-#define get_row_gpio_val(x) 0
-#endif
static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
{
- struct omap_kp *omap_kp = dev_id;
+ if (cpu_is_omap44xx()) {
+ /* disable keyboard interrupt and schedule for handling */
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
- /* disable keyboard interrupt and schedule for handling */
- if (cpu_is_omap24xx()) {
- int i;
-
- for (i = 0; i < omap_kp->rows; i++) {
- int gpio_irq = gpio_to_irq(row_gpios[i]);
- /*
- * The interrupt which we're currently handling should
- * be disabled _nosync() to avoid deadlocks waiting
- * for this handler to complete. All others should
- * be disabled the regular way for SMP safety.
- */
- if (gpio_irq == irq)
- disable_irq_nosync(gpio_irq);
- else
- disable_irq(gpio_irq);
- }
+ omap_writel(omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS),
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_IRQSTATUS);
} else
/* disable keyboard interrupt and schedule for handling */
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
@@ -132,14 +123,13 @@ static void omap_kp_scan_keypad(struct o
{
int col = 0;
+ u32 *p = (u32 *) state;
/* read the keypad status */
- if (cpu_is_omap24xx()) {
- /* read the keypad status */
- for (col = 0; col < omap_kp->cols; col++) {
- set_col_gpio_val(omap_kp, ~(1 << col));
- state[col] = ~(get_row_gpio_val(omap_kp)) & 0xff;
- }
- set_col_gpio_val(omap_kp, 0);
+ if (cpu_is_omap44xx()) {
+
+ *p = omap_readl(OMAP4_KBDOCP_BASE + OMAP4_KBD_FULLCODE31_0);
+ *(p + 1) = omap_readl(OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_FULLCODE63_32);
} else {
/* disable keyboard interrupt and schedule for handling */
@@ -198,7 +188,13 @@ static void omap_kp_tasklet(unsigned lon
row, (new_state[col] & (1 << row)) ?
"pressed" : "released");
#else
- key = omap_kp_find_key(col, row);
+
+ /* Keymappings have changed in omap4.*/
+ if (cpu_is_omap44xx())
+ key = omap_kp_find_key(row, col);
+ else
+ key = omap_kp_find_key(col, row);
+
if (key < 0) {
printk(KERN_WARNING
"omap-keypad: Spurious key event %d-%d\n",
@@ -213,8 +209,16 @@ static void omap_kp_tasklet(unsigned lon
continue;
kp_cur_group = key & GROUP_MASK;
- input_report_key(omap_kp_data->input, key & ~GROUP_MASK,
- new_state[col] & (1 << row));
+
+ if (cpu_is_omap44xx())
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[row]
+ & (1 << col));
+ else
+ input_report_key(omap_kp_data->input,
+ key & ~GROUP_MASK, new_state[col]
+ & (1 << row));
+
#endif
}
}
@@ -229,14 +233,18 @@ static void omap_kp_tasklet(unsigned lon
mod_timer(&omap_kp_data->timer, jiffies + delay);
} else {
/* enable interrupts */
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp_data->rows; i++)
- enable_irq(gpio_to_irq(row_gpios[i]));
- } else {
- omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY,
+ OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
kp_cur_group = -1;
- }
+ } else {
+ omap_writew(0, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_KBD_MASKIT);
+ kp_cur_group = -1;
+ }
+
}
}
@@ -296,7 +304,7 @@ static int __devinit omap_kp_probe(struc
struct omap_kp *omap_kp;
struct input_dev *input_dev;
struct omap_kp_platform_data *pdata = pdev->dev.platform_data;
- int i, col_idx, row_idx, irq_idx, ret;
+ int i, col_idx, row_idx, ret;
if (!pdata->rows || !pdata->cols || !pdata->keymap) {
printk(KERN_ERR "No rows, cols or keymap from pdata\n");
@@ -316,7 +324,7 @@ static int __devinit omap_kp_probe(struc
omap_kp->input = input_dev;
/* Disable the interrupt for the MPUIO keyboard */
- if (!cpu_is_omap24xx())
+ if (!cpu_is_omap44xx())
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
keymap = pdata->keymap;
@@ -327,39 +335,11 @@ static int __devinit omap_kp_probe(struc
if (pdata->delay)
omap_kp->delay = pdata->delay;
- if (pdata->row_gpios && pdata->col_gpios) {
- row_gpios = pdata->row_gpios;
- col_gpios = pdata->col_gpios;
- }
-
omap_kp->rows = pdata->rows;
omap_kp->cols = pdata->cols;
- if (cpu_is_omap24xx()) {
- /* Cols: outputs */
- for (col_idx = 0; col_idx < omap_kp->cols; col_idx++) {
- if (gpio_request(col_gpios[col_idx], "omap_kp_col") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- col_gpios[col_idx]);
- goto err1;
- }
- gpio_direction_output(col_gpios[col_idx], 0);
- }
- /* Rows: inputs */
- for (row_idx = 0; row_idx < omap_kp->rows; row_idx++) {
- if (gpio_request(row_gpios[row_idx], "omap_kp_row") < 0) {
- printk(KERN_ERR "Failed to request"
- "GPIO%d for keypad\n",
- row_gpios[row_idx]);
- goto err2;
- }
- gpio_direction_input(row_gpios[row_idx]);
- }
- } else {
- col_idx = 0;
- row_idx = 0;
- }
+ col_idx = 0;
+ row_idx = 0;
setup_timer(&omap_kp->timer, omap_kp_timer, (unsigned long)omap_kp);
@@ -369,7 +349,7 @@ static int __devinit omap_kp_probe(struc
ret = device_create_file(&pdev->dev, &dev_attr_enable);
if (ret < 0)
- goto err2;
+ goto err1;
/* setup input device */
__set_bit(EV_KEY, input_dev->evbit);
@@ -387,47 +367,54 @@ static int __devinit omap_kp_probe(struc
ret = input_register_device(omap_kp->input);
if (ret < 0) {
printk(KERN_ERR "Unable to register omap-keypad input device\n");
- goto err3;
+ goto err2;
}
- if (pdata->dbounce)
- omap_writew(0xff, OMAP_MPUIO_BASE + OMAP_MPUIO_GPIO_DEBOUNCING);
+ if (pdata->dbounce) {
+ if (cpu_is_omap44xx())
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP4_KBD_DEBOUNCINGTIME);
+ else
+ omap_writew(0xff, OMAP_MPUIO_BASE +
+ OMAP_MPUIO_GPIO_DEBOUNCING);
+ }
/* scan current status and enable interrupt */
omap_kp_scan_keypad(omap_kp, keypad_state);
- if (!cpu_is_omap24xx()) {
- omap_kp->irq = platform_get_irq(pdev, 0);
- if (omap_kp->irq >= 0) {
- if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
- "omap-keypad", omap_kp) < 0)
- goto err4;
- }
+
+ /* Configuring OMAP4 keypad registers */
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_SYSCONFIG_SOFTRST |
+ OMAP4_KBD_SYSCONFIG_ENAWKUP, OMAP4_KBDOCP_BASE
+ + OMAP4_KBD_SYSCONFIG);
+ omap_writew((OMAP4_KBD_CTRLPTVVALUE << OMAP4_KBD_CTRLPTV) |
+ OMAP4_KBD_CTRL_NOSOFTMODE,
+ OMAP4_KBDOCP_BASE + OMAP4_KBD_CTRL);
+ }
+
+ omap_kp->irq = platform_get_irq(pdev, 0);
+
+ if (omap_kp->irq >= 0) {
+ if (request_irq(omap_kp->irq, omap_kp_interrupt, 0,
+ "omap-keypad", omap_kp) < 0)
+ goto err3;
+ }
+
+ if (!cpu_is_omap44xx())
omap_writew(0, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
- } else {
- for (irq_idx = 0; irq_idx < omap_kp->rows; irq_idx++) {
- if (request_irq(gpio_to_irq(row_gpios[irq_idx]),
- omap_kp_interrupt,
- IRQF_TRIGGER_FALLING,
- "omap-keypad", omap_kp) < 0)
- goto err5;
- }
+
+ if (cpu_is_omap44xx()) {
+ omap_writew(OMAP4_KBD_IRQENABLE_EVENTEN |
+ OMAP4_KBD_IRQENABLE_LONGKEY, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
}
return 0;
-err5:
- for (i = irq_idx - 1; i >=0; i--)
- free_irq(row_gpios[i], 0);
-err4:
+err3:
input_unregister_device(omap_kp->input);
input_dev = NULL;
-err3:
- device_remove_file(&pdev->dev, &dev_attr_enable);
err2:
- for (i = row_idx - 1; i >=0; i--)
- gpio_free(row_gpios[i]);
+ device_remove_file(&pdev->dev, &dev_attr_enable);
err1:
- for (i = col_idx - 1; i >=0; i--)
- gpio_free(col_gpios[i]);
-
kfree(omap_kp);
input_free_device(input_dev);
@@ -440,14 +427,10 @@ static int __devexit omap_kp_remove(stru
/* disable keypad interrupt handling */
tasklet_disable(&kp_tasklet);
- if (cpu_is_omap24xx()) {
- int i;
- for (i = 0; i < omap_kp->cols; i++)
- gpio_free(col_gpios[i]);
- for (i = 0; i < omap_kp->rows; i++) {
- gpio_free(row_gpios[i]);
- free_irq(gpio_to_irq(row_gpios[i]), 0);
- }
+ if (cpu_is_omap44xx()) {
+ omap_writel(OMAP4_KBD_IRQDISABLE, OMAP4_KBDOCP_BASE +
+ OMAP4_KBD_IRQENABLE);
+ free_irq(omap_kp->irq, 0);
} else {
omap_writew(1, OMAP_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
free_irq(omap_kp->irq, 0);
^ permalink raw reply [flat|nested] 88+ messages in thread
end of thread, other threads:[~2018-07-06 21:18 UTC | newest]
Thread overview: 88+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-11 14:16 No subject Sammy Chan
-- strict thread matches above, loose matches on Subject: below --
2018-07-06 21:16 Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:18 ` Santosh Shilimkar
2018-06-23 21:08 David Lechner
2018-05-04 20:06 Bjorn Helgaas
2018-04-20 8:02 Christoph Hellwig
2018-04-16 1:22 Andrew Worsley
2017-11-30 10:25 Mary Cuevas
2017-08-22 1:38 Nicholas Piggin
2017-06-26 13:16 [PATCH] arm64: use readq() instead of readl() to read 64bit entry_point Luc Van Oostenryck
2017-07-03 23:46 ` No subject Khuong Dinh
2017-06-04 11:59 Yury Norov
[not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
2017-05-04 16:44 ` gengdongjiu
2017-01-31 7:58 Andy Gross
2016-12-01 10:00 Ramana Radhakrishnan
2016-11-11 3:38 Chunyan Zhang
2016-09-30 14:37 Maxime Ripard
2016-07-10 9:24 Neil Armstrong
2016-04-22 8:25 Daniel Lezcano
2016-04-22 8:27 ` Daniel Lezcano
2016-04-11 7:51 Paul Walmsley
2015-12-13 21:57 何旦洁
2015-10-27 0:44 xuyiping
[not found] <E1ZqY3A-0004Mt-KH@feisty.vs19.net>
2015-10-26 3:21 ` Jiada Wang
2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
2015-07-22 14:05 Chunfeng Yun
2015-07-15 9:32 Yuan Yao
2015-05-18 20:00 raghu MG
2015-04-21 10:18 Ard Biesheuvel
2015-02-26 16:56 Jorge Ramirez-Ortiz
2015-02-18 16:14 Lee Jones
2014-10-28 14:13 Mark Rutland
2014-09-22 19:41 Santosh Shilimkar
2014-09-22 7:45 Jingchang Lu
2014-07-09 17:49 Sebastian Andrzej Siewior
2014-05-24 1:21 Loc Ho
2014-05-12 16:40 Santosh Shilimkar
2014-05-12 16:38 Santosh Shilimkar
2014-02-22 15:53 Hans de Goede
2014-01-21 4:09 John Tobias
2014-01-16 16:11 Loc Ho
2014-01-16 16:09 Loc Ho
2014-01-13 10:32 Lothar Waßmann
2014-01-13 10:29 Lothar Waßmann
2013-12-12 7:30 Loc Ho
2013-11-01 7:04 Xiubo Li
2013-09-24 3:13 Rohit Vaswani
2013-09-02 17:01 Drasko DRASKOVIC
2013-08-24 9:29 Haojian Zhuang
2013-07-26 10:05 Haojian Zhuang
2013-06-28 5:49 Wang, Yalin
2013-06-19 10:57 Ben Dooks
2013-04-24 18:07 Viral Mehta
2012-12-29 9:17 steve.zhan
2012-11-08 8:07 Abhimanyu Kapur
2012-10-14 10:05 Alexey Dobriyan
2012-08-27 6:40 Simon Horman
2012-06-21 18:26 Paul Walmsley
2012-06-06 10:33 Sascha Hauer
2012-05-18 12:27 Sascha Hauer
2012-03-20 18:28 John Szakmeister
2011-12-28 14:01 Shawn Guo
2011-12-02 16:01 Will Deacon
2011-11-28 2:35 Jett.Zhou
2011-09-19 1:45 Saleem Abdulrasool
2011-09-15 2:03 Jongpill Lee
2011-07-21 11:12 Padmavathi Venna
2011-06-27 20:47 John Ogness
2011-06-27 20:47 Jongpill Lee
2011-06-13 17:29 Andre Silva
2011-06-05 18:33 Hector Oron
2011-05-17 9:28 Javier Martin
2011-05-13 19:35 Vadim Bendebury
2011-03-01 14:02 Javier Martin
2011-01-13 9:13 Uwe Kleine-König
2010-12-03 1:08 tarek attia
2010-10-08 6:02 Daein Moon
2010-09-09 3:33 tarek attia
2010-06-24 13:48 Uwe Kleine-König
2010-06-07 17:58 Dave Hylands
2010-05-18 10:38 Marek Szyprowski
2010-04-17 21:43 nelakurthi koteswararao
2010-02-25 9:36 Thomas Weber
2009-09-17 9:37 Marc Kleine-Budde
2009-09-07 14:07 Somshekar ChandrashekarKadam
2009-08-25 10:34 Syed Rafiuddin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).