On 16/04/14 19:11, Joachim Eastwood wrote:
On 16 April 2014 07:40, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 15/04/14 20:36, Joachim Eastwood wrote:
Hello,
I am trying to get HDMI work with DT on my VAR-STK-OM44 (4460) board.
But during kernel boot I get the following message:
[
I noticed a regression where the omap sys_clkreq signal will never
trigger for omap3 when booted with device tree while it triggers
when booted in legacy mode. This means voltage scaling does not
do anything when booted with device tree.
Turns out the reason is we fail to initialize the
Hi Paul,
thanks for the reply!
If omap_device_alloc is given 2 or more struct omap_hwmod it will try
to register the 'main_clk' of each of them with the same alias - fck -
against the same device. This fails. So to avoid a warning, don't even
try.
Signed-off-by: NeilBrown
On 17 April 2014 09:24, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 16/04/14 19:11, Joachim Eastwood wrote:
On 16 April 2014 07:40, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 15/04/14 20:36, Joachim Eastwood wrote:
Hello,
I am trying to get HDMI work with DT on my VAR-STK-OM44 (4460)
On 17 April 2014 10:56, Joachim Eastwood manab...@gmail.com wrote:
On 17 April 2014 09:24, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 16/04/14 19:11, Joachim Eastwood wrote:
On 16 April 2014 07:40, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 15/04/14 20:36, Joachim Eastwood wrote:
* Lee Jones lee.jo...@linaro.org [140417 01:01]:
I noticed a regression where the omap sys_clkreq signal will never
trigger for omap3 when booted with device tree while it triggers
when booted in legacy mode. This means voltage scaling does not
do anything when booted with device tree.
* Nishanth Menon n...@ti.com [140325 08:05]:
On 03/21/2014 12:20 AM, Lokesh Vutla wrote:
From: Dave Gerlach d-gerl...@ti.com
Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot
Hi Tomi,
My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
now working (thanks) I also taken a look at panel-dpi.
I found the DT patch for panel-dpi on the mailing list.
OMAPDSS: panel-dpi: Add DT support:
http://marc.info/?l=devicetreem=139030201815380w=2
And I got my
* Joachim Eastwood manab...@gmail.com [140417 11:05]:
Hi Tomi,
My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
now working (thanks) I also taken a look at panel-dpi.
I found the DT patch for panel-dpi on the mailing list.
OMAPDSS: panel-dpi: Add DT support:
Move the L3 master structure out of the static definition to enable
reuse for other SoCs.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: no functional change, just reordering
V1: https://patchwork.kernel.org/patch/3984151/
drivers/bus/omap_l3_noc.h | 15 +++
1 file changed, 11
From: Rajendra Nayak rna...@ti.com
On DRA7, unlike on OMAP4 and OMAP5, the flag mux input numbers used
to indicate the source of errors are not continous. Have a way in the
driver to catch these and WARN the user of the flag mux input thats
either undocumented or wrong.
In the similar vein,
The logic between handling CUSTOM_ERROR and STANDARD_ERROR is just the
reporting style.
So make it generic, simplify and standardize the reporting with both
master and target information printed to log.
Handle the register address difference for master code for standard
error and custom error as
Currently the target instance information is organized indexed by bit
field offset into multiple arrays.
1. We currently have offsets specific to each target associated with each
clock domains are in seperate arrays:
l3_targ_inst_clk1
l3_targ_inst_clk2
l3_targ_inst_clk3
2. Then they are
From: Sricharan R r.sricha...@ti.com
DRA7xx SoC has the same l3-noc interconnect ip (as OMAP4 and OMAP5), but
AM437x SoC has just 2 modules instead of 3 which other SoCs have.
So, stop using direct access of array indices and use of-match data and
simplify implementation to benefit future usage.
From: Sricharan R r.sricha...@ti.com
Since omap_l3_noc driver is now being used for OMAP5 and reusable with
DRA7 and AM437x, using omap4 specific naming is misleading.
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: reordered the patch
V1:
This allows us to encompass target information and flag mux offset that
points to the target information into a singular structure. This saves
us the need to look up two different arrays indexed by module ID for
information.
This allows us to reduce the static target information allocation to
From: Rajendra Nayak rna...@ti.com
DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
0x4400 0x100 is clk1 and clk2 is the sub clock domain
0x4500 0x1000 is clk3
Add all the
While OMAP4 and OMAP5 had 3 separate clock domains, DRA7 has only 2
and the first one then is internally divided into 2 sub clock domains.
To better represent this in the driver, we use the concept of submodule.
The address defintions in the devicetree is as per the high level
clock
On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
This is an embarrassing patch :(.
Texas Corporation does not make OMAP. Texas Instruments Inc does.
Yeah..
For that matter I dont seem to be able to find a Texas Corporation on
the internet either.
:D
While at it, update
On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
From: Sricharan R r.sricha...@ti.com
Since omap_l3_noc driver is now being used for OMAP5 and reusable with
DRA7 and AM437x, using omap4 specific naming is misleading.
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by:
On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
we do not use iclk directly anymore. And, even if we had to, we
should be using pm_runtime APIs to do the same to be completely SoC
independent.
Signed-off-by: Nishanth Menon n...@ti.com
---
Acked-by: Santosh Shilimkar
L3 error may be triggered using Debug interface (example JTAG) or
due to other errors, for example an opcode fetch (due to function
pointer or stack corruption) or a data access (due to some other
failure). NOC registers contain additional information to help aid
debug information.
With this, we
The following V2 of the series is based on v3.15-rc1 + peter's patch series:
patch #1: https://patchwork.kernel.org/patch/3923141/
(drivers: bus: omap_l3: Convert to use devm_kzalloc)
patch #2: https://patchwork.kernel.org/patch/3923061/
(drivers: bus: omap_l3:
Nishant,
On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
The following V2 of the series is based on v3.15-rc1 + peter's patch series:
patch #1: https://patchwork.kernel.org/patch/3923141/
(drivers: bus: omap_l3: Convert to use devm_kzalloc)
patch #2:
l3-dev is not populated, so populate it and use it to print information
relevant to the device instead of using a generic pr_*.
Signed-off-by: Nishanth Menon n...@ti.com
---
v2: reordering, dropped the warn change as centralizing patch follows
v1: https://patchwork.kernel.org/patch/3984221/
On 17 April 2014 21:22, Tony Lindgren t...@atomide.com wrote:
* Joachim Eastwood manab...@gmail.com [140417 11:05]:
Hi Tomi,
My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
now working (thanks) I also taken a look at panel-dpi.
I found the DT patch for panel-dpi on
This is an embarrassing patch :(.
Texas Corporation does not make OMAP. Texas Instruments Inc does.
For that matter I dont seem to be able to find a Texas Corporation on
the internet either.
While at it, update coverage to the current year and update the template
to remove redundant information
Current interrupt handler does the first level parse to identify the
slave and then handles the slave even identification, reporting and
clearing of event as well. It is hence logical to split the handler
into two where the primary handler just parses the flagmux till it
identifies a slave and the
just simplify derefencing that is equivalent.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: just ordering change
V1: https://patchwork.kernel.org/patch/3984201/
drivers/bus/omap_l3_noc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/omap_l3_noc.c
we do not use iclk directly anymore. And, even if we had to, we
should be using pm_runtime APIs to do the same to be completely SoC
independent.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: no change, just reorder
V1: https://patchwork.kernel.org/patch/3984161/
drivers/bus/omap_l3_noc.h |
As per Documentation (OMAP4+), then masterid is infact encoded as
follows:
L3_TARG_STDERRLOG_MSTADDR[7:0] STDERRLOG_MSTADDR stores the NTTP
master address. The master address is the concatenation of Prefix
Initiator ConnID. It is defined on 8 bits. The 6 MSBs are used to
distinguish the different
Currently we use __raw_readl and writel in this driver, however, there
is no strict sequencing needs for this driver, hence we should be good
with the relaxed variants.
While at it, simplify address computation using variables for register.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: no
On 04/17/2014 03:57 PM, Santosh Shilimkar wrote:
I looked at the series and its looks pretty good. Thanks for fixups, updates.
For whole series,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Thanks.
Patches(including Peter's) is available here:
From: Afzal Mohammed af...@ti.com
Add AM4372 information to handle L3 error.
AM4372 has two clk domains 100f and 200s. Provide flagmux and data
associated with it.
NOTE: Timeout doesn't have STDERRLOG_MAIN register. And per hardware
team, L3 timeout error cannot be cleared the normal way (by
Hi,
On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
Currently we use __raw_readl and writel in this driver, however, there
__raw_* and *_relaxed variants are the same, just have a look asm/io.h
297 #define readb_relaxed(c) ({ u8 __r = __raw_readb(c); __r; })
298 #define
On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
Hi,
On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
Currently we use __raw_readl and writel in this driver, however, there
__raw_* and *_relaxed variants are the same, just have a look asm/io.h
Except the relaxed
Hi,
On Thu, Apr 17, 2014 at 03:49:22PM -0500, Nishanth Menon wrote:
just simplify derefencing that is equivalent.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: just ordering change
V1: https://patchwork.kernel.org/patch/3984201/
drivers/bus/omap_l3_noc.c |2 +-
1 file changed, 1
On Thu, Apr 17, 2014 at 05:56:15PM -0400, Santosh Shilimkar wrote:
On Thursday 17 April 2014 05:52 PM, Felipe Balbi wrote:
Hi,
On Thu, Apr 17, 2014 at 03:49:21PM -0500, Nishanth Menon wrote:
Currently we use __raw_readl and writel in this driver, however, there
__raw_* and *_relaxed
* Joachim Eastwood manab...@gmail.com [140417 13:51]:
On 17 April 2014 21:22, Tony Lindgren t...@atomide.com wrote:
* Joachim Eastwood manab...@gmail.com [140417 11:05]:
Hi Tomi,
My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD panel. As HDMI is
now working (thanks) I also taken a
Free the vd (virt descriptor) after the callback is called. In EDMA driver
atleast which uses virt-dma, we make use of the desc during the callback and if
its dangerously freed before the callback is called. I also noticed this in
omap-dma dmaengine driver.
Cc: Vinod Koul vinod.k...@intel.com
* Tony Lindgren t...@atomide.com [140417 15:50]:
* Joachim Eastwood manab...@gmail.com [140417 13:51]:
On 17 April 2014 21:22, Tony Lindgren t...@atomide.com wrote:
* Joachim Eastwood manab...@gmail.com [140417 11:05]:
Hi Tomi,
My VAR-DVK-OM44 (OMAP4460) has both a HDMI and a LCD
41 matches
Mail list logo
