On Wednesday 02 July 2014 05:24 PM, Nick Dyer 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 IRQ signal
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
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 l
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
Therefore I will send it a patch removing this FIXME.
Cheers Nick
On Wed, Jul 2, 2014 at 2:55 AM, Tony Lindgren wrote:
> * Nick Krause [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
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 controlled
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.
S
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 series
Hi Ohad,
>
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna 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 hwloc
On Wed, Jul 2, 2014 at 5:45 PM, Yegor Yefremov
wrote:
> On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros wrote:
>> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros wrote:
On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
> On Wed, Jun 4, 2014 at
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 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 the
Javier Martinez Canillas 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 irqchip and Patch 3
On 02 Jul 02:08 PM, Dave Airlie wrote:
> On 2 July 2014 12:31, Darren Etheridge 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 seri
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 wrote:
>> static int omap_hwspinlock_probe(struct platform_device *pdev)
>> {
>> - struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
>> + struct device_node *no
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 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 the r
On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen 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 provide compat
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. Yo
On Wed, Jul 2, 2014 at 4:54 AM, Nick Dyer 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 IRQ signal is
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 wh
On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros wrote:
> On 06/05/2014 01:07 PM, Yegor Yefremov wrote:
>> On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros wrote:
>>> On 06/04/2014 10:45 PM, Yegor Yefremov wrote:
On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori wrote:
> On Wednesday 04 June 201
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 th
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
CC: Tero Kristo
Signed-off-by: Roger Quadros
---
drivers/clk/ti/clk-7xx.c | 11 +++
1 file cha
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
---
v2: Make patch title consiste
On Tue, Jul 1, 2014 at 5:43 PM, Bin Liu wrote:
> On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García
> wrote:
>> On 1 July 2014 12:07, Yegor Yefremov wrote:
>> [..]
>>>
>>> What can be done with these error messages:
>>>
>>> of_get_named_gpiod_flags: can't parse gpios property of node
>>> '/ocp/usb
On Tue, Jul 1, 2014 at 5:37 PM, Ezequiel García
wrote:
> On 1 July 2014 12:07, Yegor Yefremov wrote:
> [..]
>>
>> What can be done with these error messages:
>>
>> of_get_named_gpiod_flags: can't parse gpios property of node
>> '/ocp/usb@4740/usb-phy@47401300[0]'
>> 47401300.usb-phy supply vc
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
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
---
drivers/phy/phy-core.c | 32
include/l
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
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 {
la
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
CC: Tero Kr
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 pow
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
---
drivers/phy/phy-core.c | 7 ---
1 file changed, 4 insertion
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
---
Documentation/devicetree/bindings/phy/phy-bindings.txt | 4
1 file changed, 4 insertions(+)
diff
The ldousb_reg regulator provides power to the USB1 and USB2
High Speed PHYs.
Signed-off-by: Roger Quadros
---
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 8308954..50f8022 100644
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.
Signed-off-by:
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
---
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 2 ++
2 files changed, 34 insertions(+)
d
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
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 [140625 15:29]:
>> O
* Tomi Valkeinen [140702 04:06]:
> On 02/07/14 10:45, Tony Lindgren wrote:
> > * Felipe Balbi [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
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 Walmsl
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 'pixelclk-act
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
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
> Tested-by: Roger Quadros
could you please Ack this one? Thanks.
cheers,
-roger
> ---
> v2:
> - added .main_clk to hwmod.
> - moved interface structure
On 02/07/14 10:45, Tony Lindgren wrote:
> * Felipe Balbi [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
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
Hello Mike,
On Wed, Jul 2, 2014 at 6:33 AM, Mike Turquette 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
>> > wrote:
>> >> Palmas class
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
---
arch/arm/mach-omap2/clkt_iclk.c |8
1 file changed, 4 inser
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
---
arch/arm/mach-omap2/clkt_dpll.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2
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
---
arch/arm/mach-omap2/clock.c | 18 +++---
arch/arm/mach-omap2/clock.h |1 +
2 files changed, 12 insertions(+), 7 deletions(-)
dif
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
---
arch/arm/mach-omap2/dpll3xxx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/
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
---
arch/arm/mach-omap2/clkt_d
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
---
arch/arm/mach-omap2/dpll44xx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/m
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
---
arch/arm/mach-omap2/clock.c | 14 ++
arch/arm/mach-omap2/clock.h | 10 ++
arch/arm/mach-omap2/io.c|2 ++
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
---
arch/arm/mach-omap2/clkt_dpll.c |2 +-
1 file changed,
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
---
arch/arm/mach-omap2/clkt_dpll.c | 34 +
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
---
arch/arm/mach-omap2/clock.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-
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
---
arch/arm/mach-omap2/dpll44xx.c |7 +++
1 file changed, 3 insertio
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
---
arch/a
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
---
arch/arm/mach-omap2/clkt_dpll.c | 60 +--
1 file changed, 32 insertions(+), 28 deletions(-)
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
i
* Felipe Balbi [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 this
* Felipe Balbi [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 within t
62 matches
Mail list logo