* Nick Krause xerofo...@gmail.com [140701 15:51]:
Hey Tony and Russel ,
There is a FIX ME message in this function of the file stated in my
subject line.
I was wondering what locking is needed here due to not having experience with
omap subsystem(s).
Looks like the locking for ocpi_enable
* Felipe Balbi ba...@ti.com [140701 14:10]:
Hi,
On Tue, Jul 01, 2014 at 04:00:20PM -0500, Darren Etheridge wrote:
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux
* Felipe Balbi ba...@ti.com [140701 12:49]:
On Tue, Jun 17, 2014 at 08:19:35AM -0500, Felipe Balbi wrote:
On Tue, Jun 17, 2014 at 04:04:51PM +0530, Sekhar Nori wrote:
ROM code on AM437x does not support writing to L2C-310 power control
register. The L2C driver, however, tries writing to
Hi,
This sets cleans up some of the omap specific clock drivers still residing
under arch/arm/mach-omap2. This set is done in preparation to migrate
these drivers eventually under drivers/clk/ti, where we don't have access
to certain board specific functionality. The basic idea of this set is to
These are SoC specific and get their init values based on the SoC type.
Previously the values were hard coded within the DPLL clock code, but
having them inside the clock features avoids runtime cpu_is_X type checks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c
This clock type declaration is no longer used as all omap4+ SoC clock
data has been moved to DT, thus remove it.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h
These are unnecessary, as the clock code is only used on OMAP4+ platforms
through clock registrations. This also allows to eventually migrate the
clock type implementation under clock driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/dpll44xx.c |7 +++
1 file
Currently DPLL code uses runtime cpu_is_343x checks to see if the DPLL
has freqsel fields in its control register or not. Instead, add a new
flag to the clk_features.flags and use this during runtime. Allows
eventual move of the DPLL code under clock driver.
Signed-off-by: Tero Kristo
Currently, same functionality is copy pasted in two locations. Instead,
add a private API for this and get rid of some duplicated code.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 60 +--
1 file changed, 32 insertions(+),
Instead, copy the used bitfield definitions to the source file. Done in
preparation to migrate the clock implementation under clock driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/dpll44xx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff
This shall be used to replace the cpu type checks around the clock code.
Actual bit values will be introduced in patches later.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c | 14 ++
arch/arm/mach-omap2/clock.h | 10 ++
The divider value provided to the _dpll_test_fint can reach value of
256 with J type DPLLs (USB etc.), which causes an overflow with the u8
datatype. Fix this by changing the parameter to be an int instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c |2 +-
Some of the machine specific header includes are no longer used, so remove
these from the source file. This allows migration of the file under clock
driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c |3 ---
1 file changed, 3 deletions(-)
diff --git
Helps to get rid of some runtime cpu_is_x checks. This also allows eventual
migration of the code under clock driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c | 18 +++---
arch/arm/mach-omap2/clock.h |1 +
2 files changed, 12 insertions(+), 7
Some of the machine specific header includes are no longer used, so remove
these from the source file. This allows migration of the file under clock
driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |3 ---
1 file changed, 3 deletions(-)
diff --git
OMAP2 DPLL code for checking whether DPLL is in bypass mode now uses
clk_features data provided during boot. This avoids the need to use
cpu_is_X type checks runtime, and allows us to eventually move the
clock code under the clock driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Instead, copy the used constants from the header file to the source file.
This allows the code to be migrated under drivers folder where we don't
have access to the OMAP specific header files.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt_iclk.c |8
1 file
Hello Mike,
On Wed, Jul 2, 2014 at 6:33 AM, Mike Turquette mturque...@linaro.org wrote:
Quoting Peter Ujfalusi (2014-06-29 22:56:55)
Hi Javier,
On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
Hello Peter,
On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi peter.ujfal...@ti.com
On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
Nick,
I have been using your for-next branch to base my development of
touchscreen support on TI's DRA7x EVM. With the recent updates,
it has worked out great and once I got the
On 02/07/14 10:45, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140701 14:10]:
Hi,
On Tue, Jul 01, 2014 at 04:00:20PM -0500, Darren Etheridge wrote:
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform.
Rajendra,
On 06/18/2014 10:50 PM, Roger Quadros wrote:
This module is needed for the SATA and PCIe PHYs.
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Roger Quadros rog...@ti.com
could you please Ack this one? Thanks.
cheers,
-roger
---
v2:
- added .main_clk to hwmod.
- moved
Rajendra,
On 06/18/2014 03:16 PM, Roger Quadros wrote:
Get rid of optional clock as that is now managed by the
AHCI platform driver.
Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..)
is passed as the second memory resource in the device tree.
Signed-off-by: Roger
Hi all,
I was trying to bring up parallel LCD on our custom board (similar to
BeagleBoard-xM) and I did it finally - but I needed to tweak hardcoded value
of 'Invert pixel clock'. Maybe I'm doing something wrong, but anyway:
According to the display-timing.txt doc the
Sekhar,
On 06/18/2014 02:19 PM, Rajendra Nayak wrote:
On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote:
+ Nishant and Rajendra for review.
On 05/05/2014 12:54 PM, Roger Quadros wrote:
Add the sysconfig class bits for the Super Speed USB
controllers
CC: Paul Walmsley p...@pwsan.com
* Tomi Valkeinen tomi.valkei...@ti.com [140702 04:06]:
On 02/07/14 10:45, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140701 14:10]:
Hi,
On Tue, Jul 01, 2014 at 04:00:20PM -0500, Darren Etheridge wrote:
Add the necessary nodes to enable the LCD controller and the
LCD panel that
On 06/30/2014 10:55 AM, Roger Quadros wrote:
On 06/26/2014 06:06 PM, Tero Kristo wrote:
On 06/26/2014 05:22 PM, Roger Quadros wrote:
+Tero
On 06/26/2014 12:36 PM, Roger Quadros wrote:
On 06/26/2014 10:31 AM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140625 15:29]:
On 06/25/2014
On 02/07/14 11:49, Sekhar Nori wrote:
On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
least a valid) choice. That's probably because the Atmel IRQ signal is
routed to our GPIO controller, which is also an IRQ
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.
This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.
Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 2 ++
2 files changed, 34
The ldousb_reg regulator provides power to the USB1 and USB2
High Speed PHYs.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index
phy-supply is a phandle to the regulator that provides power to the
PHY. This regulator is managed during the PHY power on/off sequence
by the phy core driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/phy/phy-bindings.txt | 4
1 file changed, 4
Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-core.c | 7 ---
1 file
Hi,
On DRA7-evm, the VDDA_1V8_PHY supply must be always-on for proper functioning
of the PHYs on the SoC.
The 3.3V USB supply (ldousb_reg) can be turned OFF when the High Speed USB PHYs
are not in use. We add regulator support in the PHY framework core to manage
the PHY's regulator during PHY
After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.
It can only be switched off when in PORz (power on reset).
This patch is required for proper functionality of USB, SATA
and PCIe on DRA7-evm.
CC: Rajendra Nayak
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
Tony,
make omap2plus_defconfig ;make zImage on next-20140702
LD fs/built-in.o
scripts/mod/modpost.c: In function ‘remove_dot’:
scripts/mod/modpost.c:1710:10: warning: ignoring return value of ‘strtoul’,
declared with attribute warn_unused_result [-Wunused-result]
arch/arm/kernel
Hello.
On 07/02/2014 04:03 PM, Roger Quadros wrote:
Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-core.c | 32
On 07/02/2014 07:03 AM, Roger Quadros wrote:
After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.
It can only be switched off when in PORz (power on reset).
I dont think folks know the reasoning why hardware team decided
On Tue, Jul 1, 2014 at 5:37 PM, Ezequiel García
ezequ...@vanguardiasur.com.ar wrote:
On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote:
[..]
What can be done with these error messages:
of_get_named_gpiod_flags: can't parse gpios property of node
On Tue, Jul 1, 2014 at 5:43 PM, Bin Liu binml...@gmail.com wrote:
On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García
ezequ...@vanguardiasur.com.ar wrote:
On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote:
[..]
What can be done with these error messages:
Currently, child nodes of the gpmc node are iterated and probed
regardless of their 'status' property. This means adding 'status =
disabled;' has no effect.
This patch changes the iteration to only probe nodes marked as
available.
Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar
---
v2:
On 03/07/2014 03:09 PM, Roger Quadros wrote:
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Also program USB_DLL_M2 output to half rate.
CC: Mike Turquette mturque...@linaro.org
CC: Tero Kristo t-kri...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
On 07/02/2014 04:05 PM, Nishanth Menon wrote:
On 07/02/2014 07:03 AM, Roger Quadros wrote:
After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.
It can only be switched off when in PORz (power on reset).
I dont think
On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros rog...@ti.com wrote:
On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros rog...@ti.com wrote:
On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori nsek...@ti.com wrote:
Hi,
+linux-omap, lakml
On Wed, Jul 02, 2014 at 06:00:09PM +0200, Sebastian Andrzej Siewior wrote:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The longterm goal is to provide the same functionality as the
current OMAP uart driver and hopefully DMA support
On Wed, Jul 2, 2014 at 4:54 AM, Nick Dyer nick.d...@itdev.co.uk wrote:
On 02/07/14 11:49, Sekhar Nori wrote:
On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote:
On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at
least a valid) choice. That's probably because the Atmel
Hi,
On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote:
It has been only tested as console UART.
The tty name is ttyS based instead of ttyO. How big is the pain here,
what could be the easiest way to provide compatibility?
have been considering that myself for months. You could
On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote:
It has been only tested as console UART.
The tty name is ttyS based instead of ttyO. How big is the pain here,
what could be the easiest way to
Hi Ohad,
On 07/01/2014 07:51 AM, Ohad Ben-Cohen wrote:
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and
Hi Ohad,
On 07/01/2014 07:48 AM, Ohad Ben-Cohen wrote:
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node
On 02 Jul 02:08 PM, Dave Airlie wrote:
On 2 July 2014 12:31, Darren Etheridge detheri...@ti.com wrote:
On 07/01/2014 06:39 PM, Guido Martínez wrote:
On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
[snip]
Otherwise I think this is a good and useful patch series.
Javier Martinez Canillas jav...@dowhile0.org writes:
Hi Linus,
This is a small series with trivial changes to the gpio-omap driver.
There are no functional changes. Patches 1 and 2 removes code that it's
not necessary anymore now that the driver has been converted to use the
gpiolib
Hi Ohad,
On 07/01/2014 07:26 AM, Ohad Ben-Cohen wrote:
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify
Hi Ohad,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
2. The of_hwspin_lock_simple_xlate() is a simple default
translator function for hwspinlock provider implementations
that use a single cell number for requesting a specific lock
(relatively indexed) within a
On Wed, Jul 2, 2014 at 5:45 PM, Yegor Yefremov
yegorsli...@googlemail.com wrote:
On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros rog...@ti.com wrote:
On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros rog...@ti.com wrote:
On 06/04/2014 10:45 PM, Yegor
Hi Ohad,
The following two patches allow the OMAP hwspinlock driver
to be enabled for AM33xx, AM437x and DRA7xx SoCs.
The patches are rebased onto 3.16-rc3 and are identical to those
posted in the OMAP hwspinlock DT support v5 series [1][2]. Posting
these separately to decouple from the DT
HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.
Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software
Therefore I will send it a patch removing this FIXME.
Cheers Nick
On Wed, Jul 2, 2014 at 2:55 AM, Tony Lindgren t...@atomide.com wrote:
* Nick Krause xerofo...@gmail.com [140701 15:51]:
Hey Tony and Russel ,
There is a FIX ME message in this function of the file stated in my
subject line.
I
This removes the FIXME message above ocpi_enable being declared
for proper locking in this function. As of the current kernel
verisons there is no need for locking as only one driver uses
this function currently and therefore there is no need for real
locking requirements.
Signed-off-by: Nicholas
Hey Kevin,
When using csope I get a FIXME message on lines , 321 -325 in
arch/arm/mach-omap2/gpmc-onenand.c on the latest 3.16 r4 code. I was
wondering
if I can remove the legacy code or is it needed still for certain
mach-omap2 based boards.
Cheers Nick
--
To unsubscribe from this list: send the
On 24/06/14 13:04, Tomi Valkeinen wrote:
Make the omapdrm driver use the new HDMI ops when possible.
omapdrm will call set_hdmi_mode (when available) to tell the encoder
driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
monitor, omapdrm will call set_hdmi_infoframe to
62 matches
Mail list logo
