Add DSS related pinmux and display data nodes required to support
DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517.
Signed-off-by: Dmitry Lifshitz
---
arch/arm/boot/dts/omap3-cm-t3517.dts | 22 +++
arch/arm/boot/dts/omap3-cm-t3530.dts | 22 +++
arch/arm/boot/dts/
On 10/14/2014 10:49 PM, Tero Kristo wrote:
> On 10/14/2014 01:47 PM, Roger Quadros wrote:
>> Hi Tero,
>>
>> The USB_DPLL doesn't have recommended M/N settings as per the TRM [1]
>> Thus the omapconf audit fails.
>>
>> Any ideas of how we can fix this up? Should we add a new clock.ops structure
>>
On Tue, Oct 14, 2014 at 08:29:26PM +0300, Jyri Sarha wrote:
> HDMI audio can not have more than 24 bits even if on i2s bus there
> would be 32 bit samples. Mark this by adding .sig_bits = 24 to
> playback stream definition.
Applied, thanks. Please use subject lines matching the style for the
subs
On Tue, Oct 14, 2014 at 08:29:27PM +0300, Jyri Sarha wrote:
> Adds .ignore_pmdown_time = true to codec driver struct.
>
> HDMI codec is currently a dummy codec and doesn't benefit from pmdown
> delay. Even if in the future the codec would controll HDMI encoder, it
> would still be a digital to dig
On Wed, Oct 15, 2014 at 10:25 AM, Ran Shalit wrote:
> Hello,
>
> Is there anyone who can please explain the relation between SW sleep
> (such as udelay), to change of C-state as done by cpuidle ?
These are two different things, Ran.
udelay is a way to put simple delay between two functions. The c
Hi,
On 14/10/14 21:28, Felipe Balbi wrote:
> if we leave __exit annotation, driver can't be unbound
> through sysfs.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video
On 14/10/14 21:28, Felipe Balbi wrote:
> without MODULE_ALIAS(), omapfb won't get loaded
> automatically.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.
On 14/10/14 21:28, Felipe Balbi wrote:
> Caused by a copy & paste error. Note that even with
> this bug AM437x SK display still works because GPIO
> mux mode is always enabled. It's still wrong to mux
> somebody else's pin.
>
> Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> isn't used for a
On 14/10/14 21:34, Felipe Balbi wrote:
> On Tue, Oct 14, 2014 at 01:28:54PM -0500, Felipe Balbi wrote:
>> without MODULE_ALIAS(), omapfb won't get loaded
>> automatically.
>>
>> Signed-off-by: Felipe Balbi
>
> little note here. This makes omapfb load automatically, but display
> still doesn't wor
HI,
On Wed, Oct 15, 2014 at 03:46:10PM +0300, Tomi Valkeinen wrote:
> On 14/10/14 21:34, Felipe Balbi wrote:
> > On Tue, Oct 14, 2014 at 01:28:54PM -0500, Felipe Balbi wrote:
> >> without MODULE_ALIAS(), omapfb won't get loaded
> >> automatically.
> >>
> >> Signed-off-by: Felipe Balbi
> >
> > li
On Wed, Oct 15, 2014 at 03:20:19PM +0300, Tomi Valkeinen wrote:
> On 14/10/14 21:28, Felipe Balbi wrote:
> > without MODULE_ALIAS(), omapfb won't get loaded
> > automatically.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 +
> > 1 file changed
On Tue, Oct 14, 2014 at 12:25:19PM -0700, Tony Lindgren wrote:
> This allows testing the watchdog easily with distros just by
> doing pkill -9 watchdog.
>
> Reported-by: Thomas Dziedzic
> Signed-off-by: Tony Lindgren
Reviewed-by: Felipe Balbi
>
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/dri
Hi,
On Wed, Oct 15, 2014 at 03:13:34PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 14/10/14 21:28, Felipe Balbi wrote:
> > if we leave __exit annotation, driver can't be unbound
> > through sysfs.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4
Hi,
On Tue, Oct 14, 2014 at 10:25:00AM +0530, Vivek Gautam wrote:
> Hi Felipe,
>
>
> On Tue, Oct 14, 2014 at 4:14 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
> >> Hi Vivek,
> >>
> >> > Exynos7 also has a separate special gate clock g
On 15/10/14 17:41, Felipe Balbi wrote:
>> Interesting. I don't know if I'm doing something funny, but without this
>> patch, I can unbind omapfb, kind of.
>>
>> "echo omapfb > unbind" goes ok, but remove is obviously not called.
>
> remove isn't called because it won't exist if it's built-in. Loo
On 15/10/14 17:38, Felipe Balbi wrote:
> On Wed, Oct 15, 2014 at 03:20:19PM +0300, Tomi Valkeinen wrote:
>> On 14/10/14 21:28, Felipe Balbi wrote:
>>> without MODULE_ALIAS(), omapfb won't get loaded
>>> automatically.
>>>
>>> Signed-off-by: Felipe Balbi
>>> ---
>>> drivers/video/fbdev/omap2/omapf
Hi,
On Wed, Oct 15, 2014 at 06:43:40PM +0300, Tomi Valkeinen wrote:
> >> Somehow omapfb device is still unbound from the driver, as I can then
> >> bind it again, causing probe to be called. Which breaks everything.
> >>
> >> I would've thought that unbinding is not possible if remove is missing,
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
> I added book keeping of whether or not the 8250-dma driver has an RX
> transfer pending or not so we don't BUG here if it calls
> dmaengine_pause() on a channel which has not a pending transfer. Guess
> what, this is not e
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
> I added book keeping of whether or not the 8250-dma driver has an RX
> transfer pending or not so we don't BUG here if it calls
> dmaengine_pause() on a channel which has not a pending transfer. Guess
> what, this is not e
Hi,
On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> This series fixes a few issues with the omap rtc-driver, cleans up a bit
> and finally adds support for the PMIC control feature found in some
> revisions of this RTC IP block.
>
> Ultimately, this allows for powering off the Bea
On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> > This series fixes a few issues with the omap rtc-driver, cleans up a bit
> > and finally adds support for the PMIC control feature found in some
> > revisions o
On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> > > This series fixes a few issues with the omap rtc-driver, cleans up a bit
> > > and final
On Tue, Oct 14, 2014 at 04:06:40AM +0200, Greg KH wrote:
> On Mon, Oct 13, 2014 at 12:43:07PM +0100, Russell King - ARM Linux wrote:
> > I think the only viable solution here is that:
> >
> > 1. We blacklist the bad compiler versions outright in the kernel.
>
> Yes, please do this, it's what we h
On Wed, Oct 15, 2014 at 10:23:10PM +0100, Russell King - ARM Linux wrote:
> As I said, I have a patch in progress, but it seems that there needed
> to be some discussion about exactly which compiler versions are affected.
> It seems that it's not as trivial as looking at the GCC bug entry.
... and
These stock GCC versions miscompile the kernel by incorrectly optimising
the function epilogue code - by first increasing the stack pointer, and
then loading entries from below the stack. This means that an opportune
interrupt or exception will corrupt the current function's saved state,
which may
On 10/15/2014 05:56 PM, Russell King wrote:
> These stock GCC versions miscompile the kernel by incorrectly optimising
> the function epilogue code - by first increasing the stack pointer, and
> then loading entries from below the stack. This means that an opportune
> interrupt or exception will c
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote:
> On 10/15/2014 05:56 PM, Russell King wrote:
> > I was in two minds whether to include 4.8.3 as Linaro released a buggy
> > toolchain which identifies itself as 4.8.3, but I decided that's also
> > a distro problem. IMHO Linaro should
On 10/15/2014 08:18 PM, Russell King - ARM Linux wrote:
> Hence why I recommend that Linaro takes down their buggy compiler.
> Their 4.8.3 version should not be used *anywhere*, just the same as
> the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on
> ARM either.
Completely agree.
28 matches
Mail list logo
