On Tue, 13 Jan 2015 19:12:25 +0200
Jyri Sarha wrote:
> These patches are needed for Beaglebone-back HDMI audio. There is no
> direct dependency between these patches and the other (dts and ASoC)
> changes needed for the HDMI audio so these changes can be merged
> independently. I also feel that t
From: Felipe Balbi
Date: Tue, 13 Jan 2015 13:44:46 -0600
> + ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> + 0, dev_name(&pdev->dev), priv);
When a function call spans multiple lines, the argument on the second
and subsequent lines must start on the first colu
Hi Paul,
On 01/13/2015 05:29 PM, Paul Walmsley wrote:
> Hi Suman,
>
> thanks for pitching in on this!
>
> On Tue, 6 Jan 2015, Suman Anna wrote:
>
>> You have removed the return from the above block on failure. If any DT
>> entry doesn't have the reg property, this will hang the kernel boot.
>>
On Tue, Jan 13, 2015 at 03:13:56PM -0800, Tony Lindgren wrote:
> We are missing proper hooks for 81xx for reboot to work.
>
> Cc: Brian Hutchinson
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/Makefile | 1 +
> arch/arm/mach-omap2/common.h | 8
> arch/arm
On Tue, Jan 13, 2015 at 03:13:52PM -0800, Tony Lindgren wrote:
> We need to check if we got the clock before trying to do anything
> with it. Otherwise we will get something like this:
>
> Unable to handle kernel paging request at virtual address fffe
> ...
> [] (clk_prepare) from []
> (omap2
On Tue, Jan 13, 2015 at 03:13:51PM -0800, Tony Lindgren wrote:
> The support for 81xx was never working in mainline, and it
> will be only supported in device tree mode. Let's remove all
> the remaining 81xx related platform code.
you should probably also mention here that you're dropping unnecess
On Tue, Jan 13, 2015 at 02:23:26PM -0800, Tony Lindgren wrote:
> Nowadays omap2 is booting in device tree only mode so there is no
> need to keep the legacy interface around for omap2_init_irq().
>
> Cc: Felipe Balbi
> Signed-off-by: Tony Lindgren
Awesome, only one to go now.
Reviewed-by: Feli
On Tue, Jan 13, 2015 at 02:23:25PM -0800, Tony Lindgren wrote:
> On dm81xx we have 128 interrupts like am33xx has. Let's add
> compatible flags for dm814x and dm816x, and document the
> existing binding.
>
> As the dm81xx are booting in device tree only mode, we can now
> also remove ti81xx_init_i
On Tue, Jan 13, 2015 at 12:54:40PM -0800, Tony Lindgren wrote:
> * Felipe Balbi [150113 11:55]:
> > On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
> > > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > > @@ -1538,7 +1538,7 @@ stati
On Wed, 7 Jan 2015, Roger Quadros wrote:
> > From: Paul Walmsley
> > Date: Mon, 5 Jan 2015 15:49:57 -0700
> > Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
> > registers. Experimental.
> >
> > ---
> > arch/arm/mach-omap2/omap_hwmod.c | 33 +--
Hi Suman
On Tue, 6 Jan 2015, Suman Anna wrote:
> Looking at your rc3 log @
> http://www.pwsan.com/omap/testlogs/test_v3.19-rc3/20150105224749/boot/4460varsomom/,
> I do see a missing reg entry for mailbox, and that's the reason for your
> hang because of the missing bail out in your new patch.
>
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality,
The clocks on dm816x are a bit different from the other omap
variants. The clocks are sourced from a FAPLL (Flying Adder PLL)
unlike on other omaps. Other than that, it's a similar setup
to am33xx with extra muxes and dividers that can be defined
as existing component clocks.
Cc: Brian Hutchinson
This allows booting ti81xx boards with with when a .dts
file is in place.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-generic.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch
Hi,
Here are the device tree related changes to boot dm816x
boards as tested on a dm8168-evm.
Note that these depend on the other related patches I've
posted today. To make it easier to figure out what all is
needed, i've also posted a temporary test branch with all
the necessary patches applied
Hi Suman,
thanks for pitching in on this!
On Tue, 6 Jan 2015, Suman Anna wrote:
> You have removed the return from the above block on failure. If any DT
> entry doesn't have the reg property, this will hang the kernel boot.
> Just remove the "reg" entry from any of the existing DT, and you will
Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova .
I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomain
From: Aida Mynzhasova
This patch adds required definitions and structures for clockdomain
initialization, so omap3xxx_clockdomains_init() was substituted by
new ti81xx_clockdomains_init() while early initialization of
TI81XX platform.
This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patche
Hi,
These patches add the basic data needed for booting dm816x
after the fixes I posted earlier today. Note that also the
device tree related changes are needed that will be posted
in another series.
Regards,
Tony
Aida Mynzhasova (1):
ARM: OMAP2+: Add clock domain support for dm816x
Tony Li
Otherwise it will return true for cpu_is_omap34xx() which we don't
want for the clocks and hwmod. It's closer to am33xx for the clocks
and hwmod than to the omap34xx. We also want to be able to detect
814x and 816x separately as at least the clocks are different with
814x using a apll and 816x usin
Otherwise we get error "Cannot detect omap type!" and many
things can fail with following:
Unhandled fault: imprecise external abort (0xc06) at 0xc6031fb0
This is because the omap_type is being used to set up th SoC
specific functions for omaps.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
Fix dm814 and dm816 clocks and timer init.
Cc: Brian Hutchinson
Cc: Paul Walmsley
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/prm_common.c | 4
arch/arm/mach-omap2/timer.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/prm_common.
We are missing proper hooks for 81xx for reboot to work.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/common.h | 8
arch/arm/mach-omap2/ti81xx-restart.c | 31 +++
3 files chan
The support for 81xx was never working in mainline, and it
will be only supported in device tree mode. Let's remove all
the remaining 81xx related platform code.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/cclock3xxx_data.c | 6 +-
arch/arm/mach-omap2/omap_p
We need to check if we got the clock before trying to do anything
with it. Otherwise we will get something like this:
Unable to handle kernel paging request at virtual address fffe
...
[] (clk_prepare) from []
(omap2_clk_enable_init_clocks+0x50/0x8)
[] (omap2_clk_enable_init_clocks) from []
We cannot use the omap3 pm support on 81xx.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/io.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b957776..e4a5630 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/ar
Hi all,
The ti81xx support has been in a sorry half-merged state for
past few years in the mainline kernel. Let's get it working
by first fixing the issues.
Note that another series of patches is needed to add the 81xx
related data files.
Regards,
Tony
Tony Lindgren (7):
ARM: OMAP2+: Remove
On 01/13/2015 04:00 PM, Rob Herring wrote:
> On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna wrote:
>> Hi Rob,
>>
>> On 01/13/2015 02:38 PM, Rob Herring wrote:
>>> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
Drivers can use of_platform_populate() to create platform devices
for childr
Hi all,
Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x
which is a omap variant.
Regards,
Tony
Tony Lindgren (2):
clk: ti: Add support for FAPLL on dm816x
clk: ti: Initialize clocks for dm816x
.../devicetree/bindings/clock/ti/fapll.txt | 33 ++
drivers/clk/ti
On dm816x the clocks are sourced from a FAPLL (Flying Adder PLL)
that does not seem to be used on the other omap variants.
There are four instances of the FAPLL on dm816x that each have three
to seven child synthesizers.
I've set up the FAPLL as a single fapll.c driver. Later on we could
potentia
The clocks on ti81xx are not compatible with omap3. On dm816x
the clock source is a FAPLL (Flying Adder PLL), and on dm814x
there seems to be an APLL (All Digital PLL).
Let's fix up things for dm816x in preparation for adding the
FAPLL support. As we already have a dummy ti81xx_dt_clk_init()
in pl
Hi Rob,
On 01/13/2015 04:27 PM, Rob Herring wrote:
> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
>> Drivers can use of_platform_populate() to create platform devices
>> for children of the device main node, and a complementary API
>> of_platform_depopulate() is provided to delete these chi
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
> Drivers can use of_platform_populate() to create platform devices
> for children of the device main node, and a complementary API
> of_platform_depopulate() is provided to delete these child devices.
> Any platform_data supplied for the OF devic
On dm81xx we have 128 interrupts like am33xx has. Let's add
compatible flags for dm814x and dm816x, and document the
existing binding.
As the dm81xx are booting in device tree only mode, we can now
also remove ti81xx_init_irq() legacy function.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-b
Nowadays omap2 is booting in device tree only mode so there is no
need to keep the legacy interface around for omap2_init_irq().
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
drivers/irqchip/irq-omap-intc.c | 8
include/linux/irqchip/irq-omap-intc.h | 1 -
2 files changed, 9
Hi,
Here's a patch to get the ti81xx interrupt support working properly,
and to remove some unused legacy code.
Regards,
Tony
clone of "xxx-81xx-mainline"
Tony Lindgren (2):
irqchip: omap-intc: Fix support for dm814 and dm816
irqchip: omap-intc: Remove unused legacy interface for omap2
.
On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna wrote:
> Hi Rob,
>
> On 01/13/2015 02:38 PM, Rob Herring wrote:
>> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
>>> Drivers can use of_platform_populate() to create platform devices
>>> for children of the device main node, and a complementary API
Hi Rob,
On 01/13/2015 02:38 PM, Rob Herring wrote:
> On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
>> Drivers can use of_platform_populate() to create platform devices
>> for children of the device main node, and a complementary API
>> of_platform_depopulate() is provided to delete these chi
From: Tony Lindgren
Date: Tue, 13 Jan 2015 11:54:16 -0800
> * Tom Lendacky [150113 11:51]:
>> On 01/13/2015 01:29 PM, Tony Lindgren wrote:
>> >We only use clk_get() to get the frequency, the rest is done by
>> >the runtime PM calls. Let's free the clock too.
>> >
>> >Cc: Brian Hutchinson
>> >Cc
On Tue, Jan 13, 2015 at 12:54:40PM -0800, Tony Lindgren wrote:
> * Felipe Balbi [150113 11:55]:
> > On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
> > > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > > @@ -1538,7 +1538,7 @@ stati
* Felipe Balbi [150113 11:55]:
> On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
> > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > @@ -1538,7 +1538,7 @@ static int emac_dev_open(struct net_device *ndev)
> > int i = 0;
> > s
On Tuesday 13 January 2015 21:42:20 Tony Lindgren wrote:
> * Arnd Bergmann [150113 12:27]:
> > On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
> > > It seems we can now drop omap3517 legacy booting support
> > > to get a bit closer to making all of omap3 boot in device
> > > tree only mod
* Arnd Bergmann [150113 12:27]:
> On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
> >
> > It seems we can now drop omap3517 legacy booting support to get
> > a bit closer to making all of omap3 boot in device tree only mode.
> >
> > All these boards have at least minimal support for boo
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna wrote:
> Drivers can use of_platform_populate() to create platform devices
> for children of the device main node, and a complementary API
> of_platform_depopulate() is provided to delete these child platform
> devices. The of_platform_depopulate() lever
On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
>
> It seems we can now drop omap3517 legacy booting support to get
> a bit closer to making all of omap3 boot in device tree only mode.
>
> All these boards have at least minimal support for booting with
> device tree, and pretty much anyt
On Tue, Jan 13, 2015 at 11:59:58AM -0800, Tony Lindgren wrote:
> * Felipe Balbi [150113 11:57]:
> > On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
> > > Some devices like dm816x have the MDIO registers within the first EMAC
> > > instance address space. Let's fix the issue by allow
* Felipe Balbi [150113 11:54]:
> On Tue, Jan 13, 2015 at 01:48:24PM -0600, Tom Lendacky wrote:
> > On 01/13/2015 01:29 PM, Tony Lindgren wrote:
> > >We only use clk_get() to get the frequency, the rest is done by
> > >the runtime PM calls. Let's free the clock too.
> > >
> > >Cc: Brian Hutchinson
* Felipe Balbi [150113 11:57]:
> On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
> > Some devices like dm816x have the MDIO registers within the first EMAC
> > instance address space. Let's fix the issue by allowing to pass an
> > optional second IO range for the EMAC control regist
* Tom Lendacky [150113 11:51]:
> On 01/13/2015 01:29 PM, Tony Lindgren wrote:
> >We only use clk_get() to get the frequency, the rest is done by
> >the runtime PM calls. Let's free the clock too.
> >
> >Cc: Brian Hutchinson
> >Cc: Felipe Balbi
> >Signed-off-by: Tony Lindgren
> >---
> > drivers
On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
> Some devices like dm816x have the MDIO registers within the first EMAC
> instance address space. Let's fix the issue by allowing to pass an
> optional second IO range for the EMAC control register area.
>
> Cc: Brian Hutchinson
> Cc
On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
> Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support")
> added support for runtime PM, but it causes issues on omap3 related devices
> that actually gate the clocks:
>
> Unhandled fault: external abort on non-lin
On Tue, Jan 13, 2015 at 01:48:24PM -0600, Tom Lendacky wrote:
> On 01/13/2015 01:29 PM, Tony Lindgren wrote:
> >We only use clk_get() to get the frequency, the rest is done by
> >the runtime PM calls. Let's free the clock too.
> >
> >Cc: Brian Hutchinson
> >Cc: Felipe Balbi
> >Signed-off-by: Tony
* Felipe Balbi [150113 11:40]:
> On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
> >
> > Note that eventually we should handle the RX and TX interrupts
> > separately like cpsw is now doing. However, so far I have not seen
> > any issues with this based on my testing, so it seems t
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
drivers/net/ethernet/ti/davinci_emac.c | 1 +
1 file changed,
Now we can introduce dedicated IRQ handlers
for each of the IRQ events. This helps with
cleaning up a little bit of the clutter in
cpsw_interrupt() while also making sure that
TX IRQs will try to handle TX buffers while
RX IRQs will try to handle RX buffers.
Signed-off-by: Felipe Balbi
---
drive
CPSW never uses RX_THRESHOLD or MISC interrupts. In
fact, they are always kept masked in their appropriate
IRQ Enable register.
Instead of allocating an IRQ that never fires, it's best
to remove that code altogether and let future patches
implement it if anybody needs those.
Signed-off-by: Felipe
This patch is in preparation for a nicer IRQ
handling scheme where we use different IRQ
handlers for each IRQ line (as it should be).
Later, we will also drop IRQs offset 0 and 3
because they are always disabled in this driver.
Signed-off-by: Felipe Balbi
---
drivers/net/ethernet/ti/cpsw.c | 62
On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
> On davinci_emac, we have pulse interrupts. This means that we need to
> clear the EOI bits when disabling interrupts as otherwise the interrupts
> keep happening. And we also need to not clear the EOI bits again when
> enabling the in
Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support")
added support for runtime PM, but it causes issues on omap3 related devices
that actually gate the clocks:
Unhandled fault: external abort on non-linefetch (0x1008)
...
[] (emac_dev_getnetstats) from [] (dev_get_stats+0x78
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
drivers/net/ethernet/ti/davinci_emac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control register area.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
drivers/net/ethernet/ti/
Looks like the phy_id is never set up beyond getting the phandle.
Note that we can remove the ifdef for phy_node as there is a stub
for of_phy_connec() if CONFIG_OF is not set.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
drivers/net/ethernet/ti/davinci_emac.c | 23 ++
On davinci_emac, we have pulse interrupts. This means that we need to
clear the EOI bits when disabling interrupts as otherwise the interrupts
keep happening. And we also need to not clear the EOI bits again when
enabling the interrupts as otherwise we will get tons of:
unexpected IRQ trap at vect
On dm816x we have two emac controllers with separate memory
areas.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 3 ++-
drivers/net/ethernet/ti/davinci_emac.c | 5 +
2 files changed, 7 inserti
Hi,
Here are some fixes for davinci_emac for the issues I've noticed
recently.
Regards,
Tony
Tony Lindgren (6):
net: davinci_emac: Fix hangs with interrupts
net: davinci_emac: Fix runtime pm calls for davinci_emac
net: davinci_emac: Free clock after checking the frequency
net: davinci_e
Call clk_prepare_enable() and clk_disable_unprepare() for cpu dai
clock and codec dai clock in dai statup and shutdown callbacks. This
to make sure the related clock are enabled when the audio device is
used.
Signed-off-by: Jyri Sarha
---
This patch is needed for Beaglebone-back HDMI audio. There
On 13/01/15 06:09, Linus Walleij wrote:
Hi Linus,
> On Mon, Jan 12, 2015 at 7:26 PM, Marc Zyngier wrote:
>
>> IMX6 has been (ab)using the gic_arch_extn to provide
>> wakeup from suspend, and it makes a lot of sense to convert
>> this code to use stacked domains instead.
>>
>> This patch does ju
On 12/01/15 19:00, Stefan Agner wrote:
> Hi Marc,
>
> On 2015-01-12 19:26, Marc Zyngier wrote:
>> IMX6 has been (ab)using the gic_arch_extn to provide
>> wakeup from suspend, and it makes a lot of sense to convert
>> this code to use stacked domains instead.
>>
>> This patch does just this, updati
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of omap3
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of omap3
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of omap3
Hi all,
It seems we can now drop omap3517 legacy booting support to get
a bit closer to making all of omap3 boot in device tree only mode.
All these boards have at least minimal support for booting with
device tree, and pretty much anything supported with the legacy
board files can be configured
This is no longer needed now that 3517 is booting in device tree
only mode.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile | 3 -
arch/arm/mach-omap2/am35xx-emac.c | 114 -
arch/arm/mach-omap2/am35xx-emac.h | 15
Add drm_i2c_encoder_attach() for attaching an already probed i2c
encoder. This is needed for instance if the encoder is probed from
device tree.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_encoder_slave.c | 51 +++
include/drm/drm_encoder_slave.h |
These patches are needed for Beaglebone-back HDMI audio. There is no
direct dependency between these patches and the other (dts and ASoC)
changes needed for the HDMI audio so these changes can be merged
independently. I also feel that these changes make sense even without
the HDMI audio.
Best rega
Add node for NXP TDA19988 encoder and refer to it in the hdmi node
instead of referring to the i2c bus where the encoder is connected to.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/b
It is more convenient to refer to the i2c slave encoder directly with
phandle than to refer to the i2c bus and to create the device "manually".
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/drm/tilcdc/slave.txt |4 +-
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 50 ++
prior to this check we are checking for word_length_16b and if word_length_16b
is false then we are returning with -EINVAL.
So at this point word_length_16b can only be true.
Signed-off-by: Sudip Mukherjee
---
drivers/video/fbdev/omap2/dss/hdmi5_core.c | 5 +
1 file changed, 1 insertion(+),
Hi,
On Tue, Jan 13, 2015 at 10:18:20AM +0530, Amit Virdi wrote:
> On 1/13/2015 12:04 AM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Jan 06, 2015 at 11:44:23AM +0530, Amit Virdi wrote:
> >>I can certainly provide the dwc3 specific kernel bootup logs, full
> >>regdump and any loglevel you wan
* Roger Quadros [150108 02:33]:
> On 08/01/15 02:16, Tony Lindgren wrote:
> > * Dmitry Lifshitz [141229 23:42]:
> >> On 12/29/2014 03:06 PM, Roger Quadros wrote:
> >>> On 28/12/14 16:30, Dmitry Lifshitz wrote:
> --- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
> +++ b/arch/arm/boot/dts/omap3
* Tomi Valkeinen [150113 02:14]:
> On 03/12/14 23:33, Marek Belisko wrote:
> > Add handling for gta04 tv out chain:
> > venc -> opa362 -> svideo
> >
> > Use invert-polarity in venc node because opa362
> > is doing polarity inversion also.
> >
> > Signed-off-by: Marek Belisko
> > ---
> > arch/a
* Roger Quadros [150113 04:26]:
> The sata_ref_clk is a reference clock to the SATA phy.
> This fixes SATA malfunction across suspend/resume or when
> SATA driver is used as a module.
>
> Signed-off-by: Roger Quadros
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/omap5.dtsi | 4 ++--
> 1
* Roger Quadros [150113 04:26]:
> The sata_ref_clk is a reference clock to the SATA phy.
> This fixes SATA malfunction across suspend/resume or when
> SATA driver is used as a module.
>
> Signed-off-by: Roger Quadros
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/dra7.dtsi | 4 ++--
> 1 f
* Roger Quadros [150113 04:26]:
> Hi,
>
> During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain
> active on the DRA7 platform. This is because the pipe3 driver doesn't shut
> them off as part of .suspend(). Patch 1 addresses this issue.
>
> SATA on both OMAP5 and DRA7 break
use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon()
is not safe as the RAMINIT register can be shared between different drivers
at least for TI SoCs.
To make the modification atomic we switch to using regmap_update_bits().
regmap_update_bits() skips writing to the register if it'
On system suspend, the runtime_suspend() driver hook doesn't get
called for USB phy and so the clocks are not disabled in the driver.
This causes the L3INIT_960M_GFCLK and L3INIT_480M_GFCLK to remain
active on the DRA7 platform while in system suspend.
In case of pcie-phy, the runtime_suspend hook
Failed test case: Boot without SATA drive connected. Suspend/resume
the board and then connect SATA drive. It fails to enumerate.
Due to Errata i783 "SATA Lockup After SATA DPLL Unlock/Relock"
we can't allow SATA DPLL to be in the unlocked state.
The SATA refclk (sata_ref_clk) is the source of the
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dt
Hi,
During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain
active on the DRA7 platform. This is because the pipe3 driver doesn't shut
them off as part of .suspend(). Patch 1 addresses this issue.
SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a
system
On 05/01/15 15:09, Rasmus Villemoes wrote:
> Assigning ddata->invert_polarity to itself is not very useful; the
> context suggests that the right-hand side should have been
> pdata->invert_polarity.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/video/fbdev/omap2/displays-new/connector-anal
On 01/01/15 17:29, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> dispc_wb_go() dispc_wb_go_busy() dispc_wb_get_framedone_irq()
> dispc_mgr_get_clock_div() dispc_wb_is_enabled() dispc_wb_enable()
> dispc_wb_setup() dispc_enable_fifomerge() dispc_wb_set_channel_in(
On 21/12/14 19:02, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> rfbi_init_display() rfbi_display_disable() rfbi_display_enable()
> rfbi_set_interface_timings() rfbi_set_data_lines() rfbi_set_pixel_size()
> rfbi_set_size() rfbi_update() rfbi_configure() rfbi_enab
On 03/12/14 23:33, Marek Belisko wrote:
> Add handling for gta04 tv out chain:
> venc -> opa362 -> svideo
>
> Use invert-polarity in venc node because opa362
> is doing polarity inversion also.
>
> Signed-off-by: Marek Belisko
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 49
> +
On Sun, Nov 30, 2014 at 01:00:01AM +0400, Alexander Kochetkov wrote:
> The first patch fix i2c-omap driver for omap2420, found by code review and
> later reported by Tony Lindgren here[1].
> Candidate for stable?
>
> The second patch unhide the reson of system lockup.
>
> The patch is rebased on
On Wed, Dec 03, 2014 at 06:33:57PM +0400, Alexander Kochetkov wrote:
> This pacth series intended for fixing problem reported
> by Tony Lindgren here[1]
>
> One of first four patched could fix the problem.
> Last patch provide event trace so I could resolve problem.
> It could be applied using 'g
This is a re-submission of patches [1/4] and [2/4] from:
http://www.spinics.net/lists/linux-usb/msg118841.html
Commit log of both these patches has been modified for aided clarity. These
patches have been rebased on Balbi's testing/next.
Patches [3/4] and [4/4] were accepted as they were.
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.
The current implementation uses list_is_last to check if the dwc3_
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer. However, the dwc3 driver must not su
1 - 100 of 103 matches
Mail list logo
