On 16.12.2013 20:34, Sebastian Reichel wrote:
Hi,
On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in
On 16.12.2013 20:34, Sebastian Reichel wrote:
Hi,
On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in
On 12.12.2013 21:55, Ben Hutchings wrote:
On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote:
On Wed, 2013-12-11 at 22:15 +, Ben Hutchings wrote:
On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote:
On 11.12.2013 23:17, Ben Hutchings wrote:
I think that's an even worse idea
On 12.12.2013 21:55, Ben Hutchings wrote:
On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote:
On Wed, 2013-12-11 at 22:15 +, Ben Hutchings wrote:
On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote:
On 11.12.2013 23:17, Ben Hutchings wrote:
I think that's an even worse idea
On 12.12.2013 00:15, Ben Hutchings wrote:
2. NVRAM reading is done by a tiny driver that is loaded based on the
platform name and updates the DT node in memory. (But I don't know how
wl1251 should decide to defer probing if it's probed before that other
driver.)
Ben.
Maybe a "hwmac"
On 11.12.2013 23:17, Ben Hutchings wrote:
I think that's an even worse idea. This is not firmware and it already
exists in separate storage.
I think that rx51_init_wl1251() in
arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC
address out of NVRAM, or if it's too early to
On 11.12.2013 23:17, Ben Hutchings wrote:
I think that's an even worse idea. This is not firmware and it already
exists in separate storage.
I think that rx51_init_wl1251() in
arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC
address out of NVRAM, or if it's too early to
On 12.12.2013 00:15, Ben Hutchings wrote:
2. NVRAM reading is done by a tiny driver that is loaded based on the
platform name and updates the DT node in memory. (But I don't know how
wl1251 should decide to defer probing if it's probed before that other
driver.)
Ben.
Maybe a hwmac property
On 08.12.2013 01:49, Steven Luo wrote:
This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.
As far as I can
On 08.12.2013 01:49, Steven Luo wrote:
This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.
As far as I can
On 08.12.2013 01:49, Steven Luo wrote:
This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.
As far as I can
On 08.12.2013 01:49, Steven Luo wrote:
This patch causes problems with DSP codecs on OMAP3 devices running
Android -- specifically, when the decoder is cleaning up after itself,
munmap() of the mapped area fails, leading to a memory leak which
eventually crashes the system.
As far as I can
On 06.12.2013 17:10, gre...@linuxfoundation.org wrote:
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote:
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported
On 06.12.2013 17:10, gre...@linuxfoundation.org wrote:
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote:
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov freemangor...@abv.bg
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need
On 05.12.2013 13:25, Tomi Valkeinen wrote:
How about the patch below? If I'm not mistaken (and I might) it reserves
separate memory area for omapfb, which is not used by CMA.
If it works, it should be extended to get the parameters via kernel
cmdline, and use that alloc only if the user
On 05.12.2013 13:25, Tomi Valkeinen wrote:
How about the patch below? If I'm not mistaken (and I might) it reserves
separate memory area for omapfb, which is not used by CMA.
If it works, it should be extended to get the parameters via kernel
cmdline, and use that alloc only if the user
with the mail itself.
Sure I will wait :)
regards,
Ivo
On 06.12.2013 09:32, Dan Carpenter wrote:
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote:
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov
Custom uuid helper function is needed only in rmgr/dbdcd.c
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
Signed-off-by: Ivaylo Dimitrov
---
drivers/staging/tidspbridge/Makefile
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov freemangor...@abv.bg
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
---
with the mail itself.
Sure I will wait :)
regards,
Ivo
On 06.12.2013 09:32, Dan Carpenter wrote:
On Fri, Dec 06, 2013 at 08:05:38AM +0200, Ivajlo Dimitrov wrote:
Hi Greg,
On 01.12.2013 19:07, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov freemangor...@abv.bg
Custom uuid helper function is needed
On 01.12.2013 21:06, Joe Perches wrote:
On Sun, 2013-12-01 at 19:07 +0200, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
[]
diff --git
On 01.12.2013 14:27, Dan Carpenter wrote:
On Sun, Dec 01, 2013 at 01:10:06PM +0100, Pavel Machek wrote:
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 1aa4a3f..a8e86cf 100644
---
On 01.12.2013 14:27, Dan Carpenter wrote:
On Sun, Dec 01, 2013 at 01:10:06PM +0100, Pavel Machek wrote:
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
b/drivers/staging/tidspbridge/rmgr/drv_interface.c
index 1aa4a3f..a8e86cf 100644
---
On 01.12.2013 21:06, Joe Perches wrote:
On Sun, 2013-12-01 at 19:07 +0200, Ivaylo DImitrov wrote:
From: Ivaylo Dimitrov freemangor...@abv.bg
Custom uuid helper function is needed only in rmgr/dbdcd.c and doesn't
need to be exported. It can also be made way simpler by using sscanf.
[]
diff
Ping?
- Original Message -
From: "Ивайло Димитров"
To: "Tomi Valkeinen"
Cc: ; ; ;
; ; ;
Sent: Tuesday, November 05, 2013 9:55 PM
Subject: Re: OMAPFB: CMA allocation failures
> Оригинално писмо
>От: Tomi Valkeinen
>Относно: Re: OMAPFB: CMA allocation
Hi,
(re-sending in plain text, sorry for the noise)
commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=930ba4a374b96560ef9fde2145cdc454a164ddcc
disables tidspbridge driver for the reasons it has a security bug and there
is no active maintainer.
I was following
Hi,
(re-sending in plain text, sorry for the noise)
commit
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=930ba4a374b96560ef9fde2145cdc454a164ddcc
disables tidspbridge driver for the reasons it has a security bug and there
is no active maintainer.
I was following
Ping?
- Original Message -
From: Ивайло Димитров freemangor...@abv.bg
To: Tomi Valkeinen tomi.valkei...@ti.com
Cc: minc...@kernel.org; pa...@ucw.cz; s...@debian.org;
pali.ro...@gmail.com; pc+n...@asdf.org; linux-kernel@vger.kernel.org;
linux...@kvack.org
Sent: Tuesday, November 05,
28 matches
Mail list logo
