* Tony Lindgren [140417 15:50]:
> * Joachim Eastwood [140417 13:51]:
> > On 17 April 2014 21:22, Tony Lindgren wrote:
> > > * Joachim Eastwood [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
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
Cc: Dan Williams
Cc: R
* Joachim Eastwood [140417 13:51]:
> On 17 April 2014 21:22, Tony Lindgren wrote:
> > * Joachim Eastwood [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 th
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_*
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
> ---
> V2: just ordering change
> V1: https://patchwork.kernel.org/patch/3984201/
> drivers/bus/omap_l3_noc.c |2 +-
> 1 file changed, 1 ins
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
>
Except the relaxed vers
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
297 #define readb_relaxed(c) ({ u8 __r = __raw_readb(c); __r; })
298 #define readw_relaxed(
From: Afzal Mohammed
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 setting
bit 31
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
>
Thanks.
>> Patches(including Peter's) is available here:
>> https://github.com/nmenon/linux-2.6-playground/commits
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 differen
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
---
V2: no functional cha
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
---
V2: no change, just reorder
V1: https://patchwork.kernel.org/patch/3984161/
drivers/bus/omap_l3_noc.h |1 -
1 fil
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
---
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 b/drivers/bus/omap_l
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
On 17 April 2014 21:22, Tony Lindgren wrote:
> * Joachim Eastwood [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.
>> OMA
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
---
v2: reordering, dropped the warn change as centralizing patch follows
v1: https://patchwork.kernel.org/patch/3984221/
drivers/bus/oma
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: https://
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: Conv
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 c
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
> ---
Acked-by: Santosh Shilimkar
--
To unsubscribe
On Thursday 17 April 2014 04:49 PM, Nishanth Menon wrote:
> From: Sricharan R
>
> 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
> Signed-off-by: Nishanth Menon
> ---
>
Acked-b
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
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 domain(module
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
just
From: Rajendra Nayak
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 data needed
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 organize
From: Sricharan R
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
Signed-off-by: Nishanth Menon
---
V2: reordered the patch
V1: https://patchwork.kernel.org/patch/3984321/
drivers/b
From: Sricharan R
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.
While at it, ren
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
Today we get error such as
L3 Custom Error: MASTER MPU TARGET L4PER2
But since the actual instruction triggerring the error Vs the point
at which we report error may not be aligned, it makes sense to try
and provide additional information - example the type of operation
that was attempted to being
From: Rajendra Nayak
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, Timeout errors in
Move the L3 master structure out of the static definition to enable
reuse for other SoCs.
Signed-off-by: Nishanth Menon
---
V2: no functional change, just reordering
V1: https://patchwork.kernel.org/patch/3984151/
drivers/bus/omap_l3_noc.h | 15 +++
1 file changed, 11 insertions(+)
* Joachim Eastwood [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:
> http://marc.info/?
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=devicetree&m=139030201815380&w=2
And I got my dis
* Nishanth Menon [140325 08:05]:
> On 03/21/2014 12:20 AM, Lokesh Vutla wrote:
> > From: Dave Gerlach
> >
> > 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 because
> > of DDR3 co
* Lee Jones [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.
> >
> > Turns o
On 17 April 2014 10:56, Joachim Eastwood wrote:
> On 17 April 2014 09:24, Tomi Valkeinen wrote:
>> On 16/04/14 19:11, Joachim Eastwood wrote:
>>> On 16 April 2014 07:40, Tomi Valkeinen wrote:
On 15/04/14 20:36, Joachim Eastwood wrote:
> Hello,
>
> I am trying to get HDMI work w
On 17 April 2014 09:24, Tomi Valkeinen wrote:
> On 16/04/14 19:11, Joachim Eastwood wrote:
>> On 16 April 2014 07:40, Tomi Valkeinen 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 ke
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: Neil
> 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 th
On 16/04/14 19:11, Joachim Eastwood wrote:
> On 16 April 2014 07:40, Tomi Valkeinen 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:
>>>
>>> [ 0.9537
42 matches
Mail list logo
