at 0x815f
>Loading Ramdisk to 8fce8000, end 847f ... OK
>Using Device Tree in place at 815f, end 815f7edb
>
> Starting kernel ...
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializ
On Mon, Nov 18, 2013 at 10:51:30PM +0100, Pali Rohár wrote:
> On Wednesday 16 October 2013 14:57:34 Herbert Xu wrote:
> > On Tue, Oct 08, 2013 at 12:04:09PM -0700, Tony Lindgren wrote:
> > > * Pali Rohár [130920 06:33]:
> > > > This driver provides kernel-side support for the Random
> > > > Number
On Monday 18 November 2013 06:21 PM, Tony Lindgren wrote:
> * Santosh Shilimkar [131118 15:11]:
>> On Monday 18 November 2013 04:58 PM, Tony Lindgren wrote:
>>> If CONFIG_SOC_HAS_REALTIME_COUNTER is not selected for omap5
>>> or dra7xx, we can get the following error:
>>>
>>> arch/arm/mach-omap2/b
* Santosh Shilimkar [131118 15:11]:
> On Monday 18 November 2013 04:58 PM, Tony Lindgren wrote:
> > If CONFIG_SOC_HAS_REALTIME_COUNTER is not selected for omap5
> > or dra7xx, we can get the following error:
> >
> > arch/arm/mach-omap2/built-in.o: In function `omap4_secondary_init':
> > :(.text+0
On Monday 18 November 2013 04:58 PM, Tony Lindgren wrote:
> If CONFIG_SOC_HAS_REALTIME_COUNTER is not selected for omap5
> or dra7xx, we can get the following error:
>
> arch/arm/mach-omap2/built-in.o: In function `omap4_secondary_init':
> :(.text+0x7ab0): undefined reference to `set_cntfreq'
>
>
On Sat, Nov 16, 2013 at 02:01:17AM +0200, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
>
On Mon, Nov 18, 2013 at 7:27 PM, Tony Lindgren wrote:
> * Tony Lindgren [131113 18:37]:
>> We still have some legacy code needing the callback functions
>> that won't work properly without platform data. To use platform
>> data for twl4030-gpio, we need to not trash the possible data.
>>
>> Cc: L
On Thu, Nov 14, 2013 at 3:35 AM, Tony Lindgren wrote:
> Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
> states in private data) improved things in general, but caused a
> regression for setting the GPIO output direction.
>
> The change reorganized twl_direction_out() and twl_
If CONFIG_SOC_HAS_REALTIME_COUNTER is not selected for omap5
or dra7xx, we can get the following error:
arch/arm/mach-omap2/built-in.o: In function `omap4_secondary_init':
:(.text+0x7ab0): undefined reference to `set_cntfreq'
Fix the issue by not trying to initalize the realtime counter
unles CON
On Wednesday 16 October 2013 14:57:34 Herbert Xu wrote:
> On Tue, Oct 08, 2013 at 12:04:09PM -0700, Tony Lindgren wrote:
> > * Pali Rohár [130920 06:33]:
> > > This driver provides kernel-side support for the Random
> > > Number Generator hardware found on OMAP34xx processors.
> > >
> > > This dr
* Lee Jones [131118 11:29]:
> On Mon, 18 Nov 2013, Tony Lindgren wrote:
>
> > * Lee Jones [131118 11:10]:
> > > > > Are you Acking this patch by the way?
> > > >
> > > > If this looks acceptable to you guys, I'd like to merge this via my
> > > > fixes
> > > > branch this week with your acks if
On Mon, 18 Nov 2013, Tony Lindgren wrote:
> * Lee Jones [131118 11:10]:
> > > > Are you Acking this patch by the way?
> > >
> > > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > > branch this week with your acks if that works for you. That way I can base
> > > my om
* Lee Jones [131118 11:10]:
> > > Are you Acking this patch by the way?
> >
> > If this looks acceptable to you guys, I'd like to merge this via my fixes
> > branch this week with your acks if that works for you. That way I can base
> > my omap legacy platform data removal patches on my fixes bra
Tony Lindgren writes:
> * Ben Gamari [131118 07:14]:
>> I'm having difficulty getting a PandaBoard ES rev. B1 to boot v3.12 and
>> linux-next (30121118). I'm booting with a brand new u-boot
>> (c2e5e802ecb7ab668ce9911b210ed68c804b349f).
>>
>> In both cases the device appears to hang shortly bef
> > Are you Acking this patch by the way?
>
> If this looks acceptable to you guys, I'd like to merge this via my fixes
> branch this week with your acks if that works for you. That way I can base
> my omap legacy platform data removal patches on my fixes branch while keep
> things working for the
Commit 26273e02a0cf (ARM: OMAP2+: Fix build for dra7xx without
omap4 and 5) attempted to fix randconfig found errors for
redefinition of omap44xx_prm_reconfigure_io_chain, but was
not enough.
We need to check for AM43XX without any omap4 or 5 related
SoCs as well. And looks like we have prm44xx.o
* Ben Gamari [131118 07:14]:
> I'm having difficulty getting a PandaBoard ES rev. B1 to boot v3.12 and
> linux-next (30121118). I'm booting with a brand new u-boot
> (c2e5e802ecb7ab668ce9911b210ed68c804b349f).
>
> In both cases the device appears to hang shortly before one would expect
> init to
Hi,
On Mon, Nov 18, 2013 at 05:46:38PM +, Lee Jones wrote:
> > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > > + { /* sentinel */ },
> > > > +};
> > > > +
> > > > /* NOTE: This driver only han
* Tony Lindgren [131113 18:36]:
> We are wrongly relying on device id for the DMA configuration
> which can lead to wrong DMA channel being selected.
>
> Fix the issue by using the standard resources like we should.
>
> Cc: Chris Ball
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Tony Lindgr
* Tony Lindgren [131113 18:37]:
> We still have some legacy code needing the callback functions
> that won't work properly without platform data. To use platform
> data for twl4030-gpio, we need to not trash the possible data.
>
> Cc: Linus Walleij
> Cc: linux-g...@vger.kernel.org
> Signed-off-b
* Tomi Valkeinen [131118 05:07]:
> On 2013-11-16 02:36, Tony Lindgren wrote:
> > In order to make the remaining omap3 boards usable with device
> > tree, we need to initialize the DPI based displays using pdata
> > until we have the DSS bindings in place.
> >
> > At least board-am3517evm.c, board
* Lee Jones [131118 09:47]:
> > > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > > + { /* sentinel */ },
> > > > +};
> > > > +
> > > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip
> > > +static struct of_dev_auxdata twl_auxdata_lookup[] = {
> > > + OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
> > > + { /* sentinel */ },
> > > +};
> > > +
> > > /* NOTE: This driver only handles a single twl4030/tps659x0 chip */
> > > static int
> > > twl_probe(struct i2c_cli
Hi,
On Mon, Nov 18, 2013 at 10:29:07AM +, Lee Jones wrote:
> > Since we still need to rely on a mix of device tree initialized
> > drivers and legacy platform data initialize drivers, let's fix
> > the passing of platform data to twl4030-gpio.
> >
> > As the twl4030 GPIO is initialized by twl
On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
2013/11/18 Michael Trimarchi :
Hi Andreas
On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interr
On Mon, Nov 18, 2013 at 03:29:01PM +, Felipe Balbi wrote:
> In the hopes that people run new kernels on
> their devices, let's add a warning message
> asking users to have their DTS file fixed.
>
> The goal is that by Linux 4.0 we will be
> able to remove support for the bogus version
> of our
In the hopes that people run new kernels on
their devices, let's add a warning message
asking users to have their DTS file fixed.
The goal is that by Linux 4.0 we will be
able to remove support for the bogus version
of our touchscreen's DTS.
Suggested-by: Mark Rutland
Signed-off-by: Felipe Balbi
Using Device Tree in place at 815f, end 815f7edb
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.12.
Hi Tomi,
Am 18.11.2013 um 14:29 schrieb Tomi Valkeinen:
> On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote:
>
>> Maybe it looks as if it is an unsolvable problem. The OPA works only if
>> acbias
>> and bypass are enabled, but is not allowed to tell that it is there.
>
> That's why the board
On 2013-11-11 20:41, Aaro Koskinen wrote:
> When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig
> (LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled,
> the following BUG is seen during the boot:
>
> [7.302154] =
> [7.307128
On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote:
> Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias
> and bypass are enabled, but is not allowed to tell that it is there.
That's why the board file or dts file is there, to have "glue" data to
make different pieces
On 2013-11-16 02:01, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw]
On 2013-11-16 02:36, Tony Lindgren wrote:
> In order to make the remaining omap3 boards usable with device
> tree, we need to initialize the DPI based displays using pdata
> until we have the DSS bindings in place.
>
> At least board-am3517evm.c, board-cm-t35.c, board-devkit8000.c,
> board-ldp.c a
Currently when DISPC is suspended, the driver stores all DISPC registers
to memory, so that they can be restored on resume. This is a bad way to
handle suspend/resume, as it's prone to failures and requires somewhat
large amount of extra space to store the registers.
A better approach is to progra
Now that the apply layer writes the registers after DISPC has been
resumed, we can remove all the context restore code.
Only _omap_dispc_initial_config call is needed on resume, which
configures the non-user-configurable registers.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc
OMAPDSS driver no longer needs dss_get_ctx_loss_count, so it can be
removed.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/display.c | 1 -
drivers/video/omap2/dss/dss.c | 16
drivers/video/omap2/dss/dss.h | 2 --
include/video/omapdss.h | 1 -
4 files changed,
The DSS core driver's suspend/resume can be cleaned up by storing the
required registers to a 'dss_context' struct, instead of having a 512
byte block of memory where the registers are directly stored.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c | 77 -
DISPC's suspend/resume works ok on mainline, but there was recently a bug with
TI's kernel containing support for newer SoCs. The bug was that not all DISPC
registers were restored correctly on resume.
While this bug is not in the mainline, I realized that the current
suspend/resume support in DIS
Add consistent debug prints on all suspend & resume callbacks in omapdss
to make it simpler to debug runtime PM.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 4
drivers/video/omap2/dss/dsi.c | 4
drivers/video/omap2/dss/dss.c | 5 +
drivers/video/omap2/ds
Use runtime PM's autosuspend support with delay of 100ms.
This will prevent the driver from turning the DSS modules off and on
multiple times e.g. when loading the module.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 5 -
drivers/video/omap2/dss/dsi.c | 5 -
dri
Functions dispc_ovl_set_fifo_threshold and
dispc_ovl_compute_fifo_thresholds need to be exported. Add the
EXPORT_SYMBOLs.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/
Fix debug prints all over omapdss:
* add missing linefeeds
* change pr_err/pr_debug to DSSERR/DSSDBG
* add missing DSS_SUBSYS_NAMEs
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c | 8
drivers/video/omap2/dss/hdmi4_core.c | 16 +---
drivers/video/om
OMAP5 has MFLAG feature in DISPC. Add the register definition and dump
it. The register is not used yet, though.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c| 4
drivers/video/omap2/dss/dispc.h| 20
drivers/video/omap2/dss/dss_featu
When omapfb does ovl->get_overlay_info, ovl->set_overlay_info, the set
function may fail even if the info has not been changed. This is because
omapdss doesn't initialize the info, but expect the caller to set valid
values.
Normally that is the case, but there is at least one corner case: if
omapf
We need the required pixel clock rate when calculating the dss fclk on
SoCs that have a dedicated DSS PLL.
This patch changes the code to pass the pck to the calc functions. The
pck rate is taken into use in the next patch.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 2 +-
Simplify dss_dump_clocks() so that it doesn't make any presumptions
about the DSS fclks nature.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/
Some of the new TI SoCs using DSS have a dedicated PLL for the DSS functional
clock. This series adds support to omapdss for that kind of clocking scheme.
This series also needs the following commits, which are now in mainline, to
work:
ARM: OMAP3: fix dpll4_m3_ck and dpll4_m4_ck dividers
ARM: OM
This patch adds support for SoCs that have a dedicated DSS PLL used for
DSS function clock.
If there is no dss parent clock defined, it is presumed that the
functionl clock rate can be set (almost) freely. The code calculates the
highest allowed fck rate, which when divided with some integer gives
The dss parent_clk_name currently points to a clock node which we use to
change the fclk rate. Now that we have CLK_SET_RATE_PARENT properly set,
we can set the rate directly to the fclk node.
However, we still need to calculate the possible clock rates. For this,
we need the rate of the parent of
Remove struct dss_clock_info, as it is not usable in a case where DSS
fclk comes from a dedicated PLL. Instead, just use the fclk rate in
place of dss_clock_info, as that is all that's needed.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 13 +-
drivers/video/omap2/ds
The driver considers OMAP2 DSS's functional clock as a fixed clock.
However, it can be changed, but the possible dividers are not continuous
which is why it was just handled as a fixed clock.
As a partial fix, this patch changes the code to handle the continous
part of the dividers, from 1 to 6. T
Rename the variables related to DSS fclk's parent: "clk_name" and
"dpll4_m4_ck", to "parent_clk_name" and "parent_clk", which much better
tell what they mean.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c | 40
1 file changed, 20 inserti
2013/11/18 Michael Trimarchi :
> Hi Andreas
>
> On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart wrote:
>> The am335x can't detect pending cirq in PM runtime suspend.
>> This patch reconfigures dat1 as a GPIO before going to suspend.
>> SDIO interrupts are detected with the GPIO, the GPIO will onl
On Fri, Nov 15, 2013 at 05:53:56PM +, Felipe Balbi wrote:
> Hi,
>
> On Fri, Nov 15, 2013 at 03:55:40PM +, Mark Rutland wrote:
> > > > > > > diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
> > > > > > > b/drivers/input/touchscreen/ti_am335x_tsc.c
> > > > > > > index e1c5300..b61df9d
On Sat, Nov 16, 2013 at 02:01:19AM +0200, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
>
On Sat, 16 Nov 2013, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw
On Sat, 16 Nov 2013, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw
On 11/16/2013 02:01 AM, Taras Kondratiuk wrote:
> From: Victor Kamensky
>
> All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[
> Since we still need to rely on a mix of device tree initialized
> drivers and legacy platform data initialize drivers, let's fix
> the passing of platform data to twl4030-gpio.
>
> As the twl4030 GPIO is initialized by twl-core.c, we need to register
> the auxdata for twl4030 GPIO in twl-core.c.
Hi Andreas
On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart wrote:
> The am335x can't detect pending cirq in PM runtime suspend.
> This patch reconfigures dat1 as a GPIO before going to suspend.
> SDIO interrupts are detected with the GPIO, the GPIO will only wake
> the module from suspend, SDIO
60 matches
Mail list logo
