On 09/04/2014 10:00 PM, pekon wrote:
Hi Tony,
On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140903 14:41]:
* Roger Quadros rog...@ti.com [140902 06:57]:
Hi Tony,
These are some of the issues I found while testing v3.17-rc3.
- Wrong ECC
Hi Suman,
On Thursday 04 September 2014 16:17:53 Suman Anna wrote:
Hi Laurent,
On Wednesday 03 September 2014 18:58:32 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:29 Suman Anna wrote:
Any device requiring to be attached to an iommu_domain must have
valid archdata containing the necessary iommu information, which
is SoC-specific. Add a check in the omap_iommu_attach_dev to make
sure
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:30 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly
The nand timings were scaled down by 2 to account for
the 2x rate returned by clk_get_rate(gpmc_fclk).
As the clock data got fixed by [1], revert back to actual
timings (i.e. scale them up by 2).
Without this NAND doesn't work on dra7-evm.
[1] - commit dd94324b983afe114ba9e7ee3649313b451f63ce
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
On Thu, Sep 04, 2014 at 05:27:28PM -0500, Suman Anna wrote:
Suman Anna (2):
iommu/omap: Check for valid archdata in attach_dev
iommu/omap: Fix iommu archdata name for DT-based devices
drivers/iommu/omap-iommu.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
On Fri, Sep 05, 2014 at 01:42:09AM +0400, Sergei Shtylyov wrote:
From: Antoine Tenart antoine.ten...@free-electrons.com
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY
Tony Lindgren t...@atomide.com writes:
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:
Linux 3.17-rc3 (2014-08-31 18:23:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
This series adds support for the ST glue logic which wraps the DWC3 controller
on STiH407 SoC family chipsets.
Changes since v5
- Use of_platform_depopulate
Changes since v4
- Fix bug with setting bits in usb control register
- Remove superflous '\n'
- Change default Kconfig to make default
This patch adds the new dwc3-st.c glue driver found on
STMicroelectronics stih407 consumer electronics SoC's into the STI
arch section of the maintainers file.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
MAINTAINERS | 1 +
1 file changed, 1
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int st_dwc3_remove(struct
On Fri, Sep 05, 2014 at 10:47:01AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+
Hi Felipe,
On Fri, 05 Sep 2014, Felipe Balbi wrote:
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
Oh sorry, not sure what happened there, thanks for fixing it up:-)
it's in my
On Fri, Sep 05, 2014 at 05:55:20PM +0100, Peter Griffin wrote:
Hi Felipe,
On Fri, 05 Sep 2014, Felipe Balbi wrote:
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
Oh
Compared to legacy booting, we don't have wake-up events enabled
for device tree based booting. This means that if deeper idle
states are enabled, the device won't wake up to UART events and
seems like it has hung.
Let's fix that by adding the wake-up interrupt. Note that we
don't need to set the
Hello Olof,
Sorry for the confusion, and thanks for the clarification.
TI folks: no new platform support will be accepted through me for any
future -rc series patchsets.
- Paul
On Sun, 31 Aug 2014, Olof Johansson wrote:
This one clearly falls into the category of new platform support,
On Thu, 28 Aug 2014, Nishanth Menon wrote:
On Thu, Aug 28, 2014 at 1:19 AM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 27 Aug 2014, Nishanth Menon wrote:
On Mon, Jul 28, 2014 at 12:34 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Monday 28 July 2014 10:59 AM, Paul Walmsley wrote:
On
On 09/05/2014 01:08 PM, Paul Walmsley wrote:
[...]
In the meanwhile, we will try to provide test logs that you may desire
for at least the platforms we have functioning and access to. please
feel free to request specific test vectors if you feel our coverage is
not good enough.
Thanks.
This is my complete queue fo the omap serial driver based on the 8250 core
code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
The runtime-pm pieces look now bug-compatible with the omap-serial driver.
Besides the runtime-om improvement I also fixed a few corner cases for
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wake up irq which should to be
requested enabled at -startup() time and disabled at -shutdown() time.
v2…v3: properly copy callbacks
v1…v2: add shutdown callback
Acked-by: Alan Cox
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code together with the 8250-core code.
There should should be hardly a noticable
There is no way to access a struct uart_8250_port for a specific
line. This is only required outside of the 8250/uart callbacks like for
devices' suspend remove callbacks. For those the 8250-core provides a
wrapper like serial8250_unregister_port() which passes the struct
to the proper function
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up-dma is set
and so
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core
serial8250_do_startup() adds UART_IER_RDI and UART_IER_RLSI to ier.
serial8250_stop_rx() should remove both.
This is what the serial-omap driver has been doing and is now moved to
the 8250-core since it does no look to be *that* omap specific.
Cc: heikki.kroge...@linux.intel.com
Signed-off-by:
The serial8250_do_startup() function unconditionally clears the
interrupts and for that it reads from the RX-FIFO without checking if
there is a byte in the FIFO or not. This works fine on OMAP4+ HW like
AM335x or DRA7.
OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for
Tony noticed that the old omap-serial driver picked the uart number
based on the hint given from device tree or platform device's id.
The 8250 based omap driver doesn't do this because the core code does
not honour the -line argument which is passed by the driver.
This patch aims to keep the same
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..078a760a4a21 100644
---
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx().
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152db4cb..f273e3811f75 100644
---
Due to UART_BUG_DMA_TX the am335x has to put the first one byte into the
TX FIFO to get things going. If we get to serial8250_tx_dma() via
__dma_tx_complete() then the DMA engine just finished and the FIFO is
full and we can't put the first byte into the TX FIFO as kick start so
we leave with THRI
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen
When viewing the /proc/interrupts, there is no information about which
GPIO bank a specific gpio interrupt is hooked on to. This is more than a
bit irritating as such information can esily be provided back to the
user and at times, can be crucial for debug.
So, instead of displaying something
With the recent pinctrl-single changes, SoCs such as OMAP family can
treat wake-up events from deeper low power states as interrupts.
This is usable when the wakeup from deeper low power states is
triggered by a different hardware mechanism tied to pinctrl compared
to the routine interrupt
Use device@address as name for device nodes.
Suggested-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
V2 of the series based on review conclusion in
https://patchwork.kernel.org/patch/4743321/
based on v3.17-rc1
Wakeup irq is a interrupt path which is provided by the pinctrl
hardware of certain SoCs such as TI's OMAP family of processors that
generates an interrupt for waking up from deep
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the
Add regulator-name properties for the regulators that don't have them,
allowing the kernel to display the name from the schematic rather than
the name of the regulator on the PMIC in order to improve diagnostics.
Signed-off-by: Mark Brown broo...@kernel.org
---
On Fri, 5 Sep 2014, Nishanth Menon wrote:
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+palmas_wake_irq,
+IRQF_ONESHOT | pdata-irq_flags,
Why is this marked
On 14:45-20140827, Nishanth Menon wrote:
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From:
Daniel,
On 13:22-20140827, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+ Daniel (cpuidle maintainer)
[...]
+static
* Nishanth Menon n...@ti.com [140905 14:16]:
On 14:45-20140827, Nishanth Menon wrote:
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
49 matches
Mail list logo
