* [PATCH v6 1/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-1-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
extern void omap_vrfb_restore_context(void);
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
#endif /* __VRFB_H */
--
1.6.3.3
^ permalink raw reply related
* [PATCH v6 0/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
From: Guruswamy Senthilvadivu @ 2010-10-08 6:44 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
From: Senthilvadivu Guruswamy <svadivu@ti.com>
The changelog till v6 are:
- Address Multi-omap build issue
- Added a check to warn the wrong usage of vrfb
in non-vrfb omap devices.
- The patch subject is as per the naming conventions
- patch 2/3 now has the changes in omap2/omapfb/Kconfig
instead of omap2/Kconfig. The functional effect remains
the same, and the place of implementation is more appropriate.
- Provide details of non-vrfb devices in commit description in patch 3/3
- Removed extra paranthesis in cpu checks
Senthilvadivu Guruswamy (3):
OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
drivers/video/omap2/omapfb/Kconfig | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++++++++++
3 files changed, 27 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] davinci: Platform support for OMAP-L137/AM17x NOR flash driver
From: Vitaly Wool @ 2010-10-08 6:44 UTC (permalink / raw)
To: Nori, Sekhar
Cc: davinci-linux-open-source@linux.davincidsp.com, Sergei Shtylyov,
Aleksey Makarov, David Griego, linux-mtd@lists.infradead.org,
Dharmappa, Savinay
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302342ADE9D@dbde02.ent.ti.com>
On Fri, Oct 8, 2010 at 5:54 AM, Nori, Sekhar <nsekhar@ti.com> wrote:
> Hi Sergei,
>
> On Thu, Oct 07, 2010 at 20:35:28, Sergei Shtylyov wrote:
>
>> > +static void da830_evm_nor_done(void *data)
>> > +{
>> > + clk_disable(da830_evm_nor.clk);
>> > + clk_put(da830_evm_nor.clk);
>> > + iounmap(da830_evm_nor.latch.addr);
>> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
>> > + iounmap(da830_evm_nor.aemif.addr);
>> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
>> > +}
>>
>> Why you've changed this function which was useful also for the error cleanup
>> before?
>
> The issues down below aside, I think goto based error handling
> is clearer to follow. Any objections to using goto based
> error handing per-se?
What you're saying just doesn't make sense in this context. Whatever
way of error handling is chosen, it first needs to be correct which is
absolutely not the case here.
~Vitaly
^ permalink raw reply
* Re: system crash at mounting of btrfs
From: Tomasz Chmielewski @ 2010-10-08 6:43 UTC (permalink / raw)
To: linux-btrfs
> I tried it with 3 kernels from the 2.5.35 series.
> My system is a AMD64, so I put one SSD disk as an external drive (USB) to a
> laptop running a 32bit system, it crashed the same at my wanting to mount the
> partition.
>
> This is my config:
> $uname -a
> Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686
> GNU/Linux
You could try:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc7-maverick/
--
Tomasz Chmielewski
http://wpkg.org
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwOyBa
YW5nIFJveS1SNjE5MTENCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAyLzddIHNwaS9tcGM4eHh4
OiByZWZhY3RvciB0aGUgY29tbW9uIGNvZGUgZm9yIFNQSS9lU1BJDQo+IGNvbnRyb2xsZXINCj4g
DQo+IE9uIFRodSwgU2VwIDMwLCAyMDEwIGF0IDA0OjAwOjQxUE0gKzA4MDAsIE1pbmdrYWkgSHUg
d3JvdGU6DQo+IFsuLi5dDQo+ID4gLXN0YXRpYyB2b2lkIG1wYzh4eHhfc3BpX2NoYW5nZV9tb2Rl
KHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpDQo+ID4gK3N0YXRpYyB2b2lkIGZzbF9zcGlfY2hhbmdl
X21vZGUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkNCj4gPiAgew0KPiA+ICAJc3RydWN0IG1wYzh4
eHhfc3BpICptc3BpID0gc3BpX21hc3Rlcl9nZXRfZGV2ZGF0YShzcGktPm1hc3Rlcik7DQo+ID4g
IAlzdHJ1Y3Qgc3BpX21wYzh4eHhfY3MgKmNzID0gc3BpLT5jb250cm9sbGVyX3N0YXRlOw0KPiA+
IC0JX19iZTMyIF9faW9tZW0gKm1vZGUgPSAmbXNwaS0+YmFzZS0+bW9kZTsNCj4gPiArCXN0cnVj
dCBmc2xfc3BpX3JlZyAqcmVnX2Jhc2UgPSAoc3RydWN0IGZzbF9zcGlfcmVnICopbXNwaS0+cmVn
X2Jhc2U7DQo+IA0KPiBObyBuZWVkIGZvciB0aGVzZSB0eXBlIGNhc3RzICh0aGUgc2FtZSBpcyBm
b3IgdGhlIHdob2xlIHBhdGNoKS4NCj4gDQoNCkZpeCBpdC4NCg0KVGhhbmtzLA0KTWluZ2thaQ0K
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Subject: Re: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI
> controller
>
> On Thu, Sep 30, 2010 at 04:00:41PM +0800, Mingkai Hu wrote:
> [...]
> > -static void mpc8xxx_spi_change_mode(struct spi_device *spi)
> > +static void fsl_spi_change_mode(struct spi_device *spi)
> > {
> > struct mpc8xxx_spi *mspi = spi_master_get_devdata(spi->master);
> > struct spi_mpc8xxx_cs *cs = spi->controller_state;
> > - __be32 __iomem *mode = &mspi->base->mode;
> > + struct fsl_spi_reg *reg_base = (struct fsl_spi_reg *)mspi->reg_base;
>
> No need for these type casts (the same is for the whole patch).
>
Fix it.
Thanks,
Mingkai
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Subject: Re: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI
> controller
>
> On Thu, Sep 30, 2010 at 04:00:41PM +0800, Mingkai Hu wrote:
> [...]
> > -static void mpc8xxx_spi_change_mode(struct spi_device *spi)
> > +static void fsl_spi_change_mode(struct spi_device *spi)
> > {
> > struct mpc8xxx_spi *mspi = spi_master_get_devdata(spi->master);
> > struct spi_mpc8xxx_cs *cs = spi->controller_state;
> > - __be32 __iomem *mode = &mspi->base->mode;
> > + struct fsl_spi_reg *reg_base = (struct fsl_spi_reg *)mspi->reg_base;
>
> No need for these type casts (the same is for the whole patch).
>
Fix it.
Thanks,
Mingkai
^ permalink raw reply
* Re: How to modify /etc/network/interfaces file in a OE recipe
From: Frans Meulenbroeks @ 2010-10-08 6:36 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTinDviTOfaSFktW0iKJPrjsT3QSHWiYLaw4WrX5K@mail.gmail.com>
2010/10/8 Khem Raj <raj.khem@gmail.com>:
> On Thu, Oct 7, 2010 at 3:54 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 10/07/2010 03:11 PM, Elvis Dowson wrote:
>>>
>>> Hi,
>>> Would someone be able to help me with modifying an
>>> omap3-console-image recipe, such that in the final image, the
>>> /etc/network/interfaces file gets edited as follows
>>>
>>> #auto eth0 <- remove # sign ( auto eth0 )
>>> #iface eth0 inet dhcp <- remove # sign ( iface eth0 inet dhcp )
>>> #iface eth1 inet dhcp
>>>
>>> I am using a Gumstix Overo + Chestnut43 expansion board, which has an
>>> inbuilt wired ethernet interface. I have to make this modification manually,
>>> to enable this interface each time. However, if I can modify the OE recipe
>>> somehow to do this it would be great. I know it can be done, but I don't
>>> know where to start and which file to modify.
>>
>> Add the file the way you like it to
>> .../openembedded/recipes/netbase/netbase/overo
>> and rebuild netbase. Use the beagleboard as an example.
>
> or use bblayers and bbappend.
Actually if you use an overlay you can just put your patch file in the
files dir of your overlay.
If I recall correctly files will be first fetched in the FILESPATHPKG
in the overlay before looking in the oe dir (assuming your layer
priorities are ok)
Have fun! Frans
^ permalink raw reply
* Re: [PATCH] cairo_1.10.0: add `glib-2.0-native` to `DEPENDS`
From: Frans Meulenbroeks @ 2010-10-08 6:28 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286499432.3659.37.camel@mattotaupa>
2010/10/8 Paul Menzel <paulepanter@users.sourceforge.net>:
> Date: Thu, 7 Oct 2010 13:38:44 +0200
>
> `do_compile()` of `cairo_1.10.0.bb` fails with the following error.
>
> […]
> make[4]: Entering directory `/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/cairo-1.10.0-r0/cairo-1.10.0/util/cairo-gobject'
> CC libcairo_gobject_la-cairo-gobject-enums.lo
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:44:25: error: glib-object.h: No such file or directory
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_context_get_type'
> cairo-gobject.h:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_device_get_type'
> cairo-gobject.h:60: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_pattern_get_type'
> […]
>
> `glib-object.h` is only in sysroot of the build host.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
>
> `cairo_1.8.8.bb` builds fine.
>
> Adding `glib-2.0-native` to `DEPENDS` puts `glib-object.h` also into the sysroot of the target machine and fixes the build.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
> angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0/glib-object.h
>
> Build tested with `angstrom-2008.1` for `MACHINE = "beagleboard"`.
>
> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> recipes/cairo/cairo_1.10.0.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/recipes/cairo/cairo_1.10.0.bb b/recipes/cairo/cairo_1.10.0.bb
> index 7530cd1..9859b9c 100644
> --- a/recipes/cairo/cairo_1.10.0.bb
> +++ b/recipes/cairo/cairo_1.10.0.bb
> @@ -1,5 +1,7 @@
> require cairo.inc
>
> +DEPENDS += "glib-2.0-native"
> +
> SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.gz;name=cairo \
> "
>
> --
Hm. Personally I'd say glib should put the include file in
angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0
I'd say you need a depend on glib-2.0 not on glib-2.0-native
As i see it, dependencies on native packages should only be needed if
you need a binary from another package to build your package (unless
ofc you are a binary package yourself, in which case you need native
headers)
(and yeah, I know there are several exceptions).
Frans
^ permalink raw reply
* RE: [PATCH v3 3/7] eSPI: add eSPI controller support
From: Hu Mingkai-B21284 @ 2010-10-08 6:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, spi-devel-general
In-Reply-To: <20101001112204.GA16783@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Friday, October 01, 2010 7:22 PM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH v3 3/7] eSPI: add eSPI controller support
>
> Hello Mingkai,
>
> There are mostly cosmetic comments down below.
>
> > + /* spin until TX is done */
> > + while (((events = mpc8xxx_spi_read_reg(®_base->event))
> > + & SPIE_NF) == 0)
> > + cpu_relax();
>
> This is dangerous. There's a handy spin_event_timeout() in asm/delay.h.
>
When timeout, can I use return in the interrupt function directly like this?
if (!(events & SPIE_NF)) {
int ret;
/* spin until TX is done */
ret = spin_event_timeout(((events = mpc8xxx_spi_read_reg(
®_base->event)) & SPIE_NF) == 0, 1000, 0);
if (!ret) {
dev_err(mspi->dev, "tired waiting for SPIE_NF\n");
return;
}
}
> > +}
> > +
> > +static const struct of_device_id of_fsl_espi_match[] = {
> > + { .compatible = "fsl,mpc8536-espi" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, of_fsl_espi_match);
> > +
> > +static struct of_platform_driver fsl_espi_driver = {
> > + .driver = {
> > + .name = "fsl_espi",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_fsl_espi_match,
> > + },
> > + .probe = of_fsl_espi_probe,
> > + .remove = __devexit_p(of_fsl_espi_remove),
> > +};
> > +
> > +static int __init fsl_espi_init(void) {
> > + return of_register_platform_driver(&fsl_espi_driver);
> > +}
> > +module_init(fsl_espi_init);
> > +
> > +static void __exit fsl_espi_exit(void) {
> > + of_unregister_platform_driver(&fsl_espi_driver);
> > +}
> > +module_exit(fsl_espi_exit);
> > +
> > +MODULE_AUTHOR("Mingkai Hu");
> > +MODULE_DESCRIPTION("Enhanced Freescale SPI Driver");
>
> This sounds like that this is an enhanced version of the Freescale SPI driver,
> which it is not. ;-)
>
I quoted from the UM, maybe the enhancement is the controller takes over the
CS signal from the HW point view.
I changed all the other code according to your comments.
Thanks,
Mingkai
^ permalink raw reply
* RE: [PATCH v3 3/7] eSPI: add eSPI controller support
From: Hu Mingkai-B21284 @ 2010-10-08 6:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, spi-devel-general
In-Reply-To: <20101001112204.GA16783@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwDQo+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMy83XSBlU1BJOiBhZGQgZVNQSSBjb250cm9sbGVyIHN1
cHBvcnQNCj4gDQo+IEhlbGxvIE1pbmdrYWksDQo+IA0KPiBUaGVyZSBhcmUgbW9zdGx5IGNvc21l
dGljIGNvbW1lbnRzIGRvd24gYmVsb3cuDQo+IA0KPiA+ICsJCS8qIHNwaW4gdW50aWwgVFggaXMg
ZG9uZSAqLw0KPiA+ICsJCXdoaWxlICgoKGV2ZW50cyA9IG1wYzh4eHhfc3BpX3JlYWRfcmVnKCZy
ZWdfYmFzZS0+ZXZlbnQpKQ0KPiA+ICsJCQkJCSYgU1BJRV9ORikgPT0gMCkNCj4gPiArCQkJY3B1
X3JlbGF4KCk7DQo+IA0KPiBUaGlzIGlzIGRhbmdlcm91cy4gVGhlcmUncyBhIGhhbmR5IHNwaW5f
ZXZlbnRfdGltZW91dCgpIGluIGFzbS9kZWxheS5oLg0KPiANCg0KV2hlbiB0aW1lb3V0LCBjYW4g
SSB1c2UgcmV0dXJuIGluIHRoZSBpbnRlcnJ1cHQgZnVuY3Rpb24gZGlyZWN0bHkgbGlrZSB0aGlz
Pw0KDQppZiAoIShldmVudHMgJiBTUElFX05GKSkgew0KICAgICAgICBpbnQgcmV0Ow0KICAgICAg
ICAvKiBzcGluIHVudGlsIFRYIGlzIGRvbmUgKi8NCiAgICAgICAgcmV0ID0gc3Bpbl9ldmVudF90
aW1lb3V0KCgoZXZlbnRzID0gbXBjOHh4eF9zcGlfcmVhZF9yZWcoDQogICAgICAgICAgICAgICAg
ICAgICAgICAmcmVnX2Jhc2UtPmV2ZW50KSkgJiBTUElFX05GKSA9PSAwLCAxMDAwLCAwKTsNCiAg
ICAgICAgaWYgKCFyZXQpIHsNCiAgICAgICAgICAgICAgICBkZXZfZXJyKG1zcGktPmRldiwgInRp
cmVkIHdhaXRpbmcgZm9yIFNQSUVfTkZcbiIpOw0KICAgICAgICAgICAgICAgIHJldHVybjsNCiAg
ICAgICAgfQ0KfQ0KDQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3Qgb2Zf
ZGV2aWNlX2lkIG9mX2ZzbF9lc3BpX21hdGNoW10gPSB7DQo+ID4gKwl7IC5jb21wYXRpYmxlID0g
ImZzbCxtcGM4NTM2LWVzcGkiIH0sDQo+ID4gKwl7fQ0KPiA+ICt9Ow0KPiA+ICtNT0RVTEVfREVW
SUNFX1RBQkxFKG9mLCBvZl9mc2xfZXNwaV9tYXRjaCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgc3Ry
dWN0IG9mX3BsYXRmb3JtX2RyaXZlciBmc2xfZXNwaV9kcml2ZXIgPSB7DQo+ID4gKwkuZHJpdmVy
ID0gew0KPiA+ICsJCS5uYW1lID0gImZzbF9lc3BpIiwNCj4gPiArCQkub3duZXIgPSBUSElTX01P
RFVMRSwNCj4gPiArCQkub2ZfbWF0Y2hfdGFibGUgPSBvZl9mc2xfZXNwaV9tYXRjaCwNCj4gPiAr
CX0sDQo+ID4gKwkucHJvYmUJCT0gb2ZfZnNsX2VzcGlfcHJvYmUsDQo+ID4gKwkucmVtb3ZlCQk9
IF9fZGV2ZXhpdF9wKG9mX2ZzbF9lc3BpX3JlbW92ZSksDQo+ID4gK307DQo+ID4gKw0KPiA+ICtz
dGF0aWMgaW50IF9faW5pdCBmc2xfZXNwaV9pbml0KHZvaWQpIHsNCj4gPiArCXJldHVybiBvZl9y
ZWdpc3Rlcl9wbGF0Zm9ybV9kcml2ZXIoJmZzbF9lc3BpX2RyaXZlcik7DQo+ID4gK30NCj4gPiAr
bW9kdWxlX2luaXQoZnNsX2VzcGlfaW5pdCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBfX2V4
aXQgZnNsX2VzcGlfZXhpdCh2b2lkKSB7DQo+ID4gKwlvZl91bnJlZ2lzdGVyX3BsYXRmb3JtX2Ry
aXZlcigmZnNsX2VzcGlfZHJpdmVyKTsNCj4gPiArfQ0KPiA+ICttb2R1bGVfZXhpdChmc2xfZXNw
aV9leGl0KTsNCj4gPiArDQo+ID4gK01PRFVMRV9BVVRIT1IoIk1pbmdrYWkgSHUiKTsNCj4gPiAr
TU9EVUxFX0RFU0NSSVBUSU9OKCJFbmhhbmNlZCBGcmVlc2NhbGUgU1BJIERyaXZlciIpOw0KPiAN
Cj4gVGhpcyBzb3VuZHMgbGlrZSB0aGF0IHRoaXMgaXMgYW4gZW5oYW5jZWQgdmVyc2lvbiBvZiB0
aGUgRnJlZXNjYWxlIFNQSSBkcml2ZXIsDQo+IHdoaWNoIGl0IGlzIG5vdC4gOy0pDQo+IA0KDQpJ
IHF1b3RlZCBmcm9tIHRoZSBVTSwgbWF5YmUgdGhlIGVuaGFuY2VtZW50IGlzIHRoZSBjb250cm9s
bGVyIHRha2VzIG92ZXIgdGhlDQpDUyBzaWduYWwgZnJvbSB0aGUgSFcgcG9pbnQgdmlldy4NCg0K
SSBjaGFuZ2VkIGFsbCB0aGUgb3RoZXIgY29kZSBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4N
Cg0KVGhhbmtzLA0KTWluZ2thaQ0KDQo=
^ permalink raw reply
* Re: system crash at mounting of btrfs
From: Gerhard Kulzer @ 2010-10-08 6:32 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <loom.20101007T155351-932@post.gmane.org>
I did an btrfs-image -c 9 dump on one partition, but it generated 142MB of data.
How can I send this?
^ permalink raw reply
* Re: [PATCH 1/4] RDEPENDS -> RDEPENDS_${PN}
From: Frans Meulenbroeks @ 2010-10-08 6:32 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286399340-15927-2-git-send-email-fransmeulenbroeks@gmail.com>
2010/10/6 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
> classes/cpan-base.bbclass | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/classes/cpan-base.bbclass b/classes/cpan-base.bbclass
> index 379defa..a04f61c 100644
> --- a/classes/cpan-base.bbclass
> +++ b/classes/cpan-base.bbclass
> @@ -5,7 +5,7 @@
> FILES_${PN} += "${libdir}/perl5 ${datadir}/perl5"
>
> DEPENDS += "${@["perl", "perl-native"][(bb.data.inherits_class('native', d))]}"
> -RDEPENDS += "${@["perl", ""][(bb.data.inherits_class('native', d))]}"
> +RDEPENDS_${PN} += "${@["perl", ""][(bb.data.inherits_class('native', d))]}"
>
> # Determine the staged version of perl from the perl configuration file
> def get_perl_version(d):
Aargh. Accidently pushed this patch yesterday with another one.
Thought I'd removed it from my git, but apparently it wasn't.
Propose to keep it like that (and no revert). Let me know if a PR bump
of recipes inheriting this is needed.
Frans.
^ permalink raw reply
* [U-Boot] [PATCH] board/mpl: Remove mpl-specific memory test command
From: "David Müller (ELSOFT AG)" @ 2010-10-08 6:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286509157.20901.13.camel@ptyser-laptop>
Peter Tyser schrieb:
> On Wed, 2010-10-06 at 22:27 +0200, Wolfgang Denk wrote:
>> I think you are right. If you have tiome, please submit patches to
>> remove these, then we will see if anybody cares.
>
> Will do.
I'm currently trying to bring the VCMA9 port in sync with the recently
introduced "ARM relocation support" feature.
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101008/11c0c3bd/attachment.pgp
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: KOSAKI Motohiro @ 2010-10-08 6:30 UTC (permalink / raw)
To: Tetsuo Handa
Cc: kosaki.motohiro, linux-kernel, takedakn, lists, kawime, jkosina,
linux-security-module
In-Reply-To: <201010080626.o986QJX4002281@www262.sakura.ne.jp>
> From cc7601c18982909987bbb48971acb86a69a3317a Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Fri, 8 Oct 2010 14:43:22 +0900
> Subject: [PATCH] TOMOYO: Print URL information before panic().
>
> Configuration files for TOMOYO 2.3 are not compatible with TOMOYO 2.2.
> But current panic() message is too unfriendly and is confusing users.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> security/tomoyo/common.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
> index c668b44..1f0d45a 100644
> --- a/security/tomoyo/common.c
> +++ b/security/tomoyo/common.c
> @@ -2051,13 +2051,22 @@ void tomoyo_check_profile(void)
> const u8 profile = domain->profile;
> if (tomoyo_profile_ptr[profile])
> continue;
> + printk(KERN_ERR "You need to define profile %u before using it.\n",
> + profile);
> + printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
> + "for more information.\n");
> panic("Profile %u (used by '%s') not defined.\n",
> profile, domain->domainname->name);
> }
> tomoyo_read_unlock(idx);
> - if (tomoyo_profile_version != 20090903)
> + if (tomoyo_profile_version != 20090903) {
> + printk(KERN_ERR "You need to install userland programs for "
> + "TOMOYO 2.3 and initialize policy configuration.\n");
> + printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
> + "for more information.\n");
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
> + }
> printk(KERN_INFO "TOMOYO: 2.3.0\n");
> printk(KERN_INFO "Mandatory Access Control activated.\n");
> }
> --
> 1.7.1
Looks good to me. thanks.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply
* [U-Boot] [PATCH] include/compiler.h: remove uint typedef for __MACH__
From: Andreas Bießmann @ 2010-10-08 6:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101006211012.49CD6153A7E@gemini.denx.de>
Dear Wolfgang Denk,
Am 06.10.2010 um 23:10 schrieb Wolfgang Denk:
> Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
>
> In message <1285429559-44573-1-git-send-email-andreas.devel@googlemail.com> you wrote:
>> ---
>> include/compiler.h | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> Applied, thanks.
>
> Best regards,
>
> Wolfgang Denk
couldn't find this patch mainline. Where did it go?
regards
Andreas Bie?mann
^ permalink raw reply
* [U-Boot] [PATCH v2] lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
From: Andreas Bießmann @ 2010-10-08 6:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101006204731.C597E153A7E@gemini.denx.de>
Dear Wolfgang Denk,
Am 06.10.2010 um 22:47 schrieb Wolfgang Denk:
> Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
>
> In message <1285966262-73388-1-git-send-email-andreas.devel@googlemail.com> you wrote:
>> lib/hashtable.c | 12 ++++++++----
>> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> Applied, thanks.
>
> Best regards,
>
> Wolfgang Denk
couldn't find this patch mainline. Where did it go?
regards
Andreas Bie?mann
^ permalink raw reply
* [Buildroot] [Bug 2677] introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2677-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2677
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2677] introducing util-linux-ng as replacement for util-linux
From: bugzilla at busybox.net @ 2010-10-08 6:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2677-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2677
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P4
Target Milestone|--- |2010.11
Severity|normal |enhancement
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [Bug 2683] cups does not install correctly to target
From: bugzilla at busybox.net @ 2010-10-08 6:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-2683-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=2683
Ossy <marcus.osdoba@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |marcus.osdoba at googlemail.co
|.org |m
Target Milestone|--- |2010.11
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: Tetsuo Handa @ 2010-10-08 6:26 UTC (permalink / raw)
To: kosaki.motohiro
Cc: linux-kernel, takedakn, lists, kawime, jkosina,
linux-security-module
In-Reply-To: <20101008134644.8049.A69D9226@jp.fujitsu.com>
Jiri Kosina wrote: ( http://lkml.org/lkml/2010/8/11/80 )
> > The panic message was:
> > > Profile %u (used by '%s') not defined.
> >
> > Profile 0 (used by '0') not defined.
>
> Looking at the code ...
>
> void tomoyo_check_profile(void)
> {
> struct tomoyo_domain_info *domain;
> const int idx = tomoyo_read_lock();
> tomoyo_policy_loaded = true;
> /* Check all profiles currently assigned to domains are defined. */
> list_for_each_entry_rcu(domain, &tomoyo_domain_list, list) {
> const u8 profile = domain->profile;
> if (tomoyo_profile_ptr[profile])
> continue;
> panic("Profile %u (used by '%s') not defined.\n",
> profile, domain->domainname->name);
> }
> tomoyo_read_unlock(idx);
> if (tomoyo_profile_version != 20090903)
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
> printk(KERN_INFO "TOMOYO: 2.3.0\n");
> printk(KERN_INFO "Mandatory Access Control activated.\n");
> }
>
> makes one wonder whether not having up-to-date userspace really does
> qualify for unconditional kernel panic.
KOSAKI Motohiro wrote:
> Handa-san, please see this panic message again.
>
> > Kernel panic - not syncing: Profile uersion 0 is not supported
>
> Profile?
> This message doesn't have any information which should we look!
> And, 'profile' is wrong word. TOMOYO have to recommend to upgrade
> userland tools here at minimum.
I see. What about this?
>From cc7601c18982909987bbb48971acb86a69a3317a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Fri, 8 Oct 2010 14:43:22 +0900
Subject: [PATCH] TOMOYO: Print URL information before panic().
Configuration files for TOMOYO 2.3 are not compatible with TOMOYO 2.2.
But current panic() message is too unfriendly and is confusing users.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
security/tomoyo/common.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
index c668b44..1f0d45a 100644
--- a/security/tomoyo/common.c
+++ b/security/tomoyo/common.c
@@ -2051,13 +2051,22 @@ void tomoyo_check_profile(void)
const u8 profile = domain->profile;
if (tomoyo_profile_ptr[profile])
continue;
+ printk(KERN_ERR "You need to define profile %u before using it.\n",
+ profile);
+ printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
+ "for more information.\n");
panic("Profile %u (used by '%s') not defined.\n",
profile, domain->domainname->name);
}
tomoyo_read_unlock(idx);
- if (tomoyo_profile_version != 20090903)
+ if (tomoyo_profile_version != 20090903) {
+ printk(KERN_ERR "You need to install userland programs for "
+ "TOMOYO 2.3 and initialize policy configuration.\n");
+ printk(KERN_ERR "Please see http://tomoyo.sourceforge.jp/2.3/ "
+ "for more information.\n");
panic("Profile version %u is not supported.\n",
tomoyo_profile_version);
+ }
printk(KERN_INFO "TOMOYO: 2.3.0\n");
printk(KERN_INFO "Mandatory Access Control activated.\n");
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] gtk+_2.20.1: add `pango-native` to `DEPENDS`
From: Frans Meulenbroeks @ 2010-10-08 6:24 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286500978.3659.60.camel@mattotaupa>
2010/10/8 Paul Menzel <paulepanter@users.sourceforge.net>:
> Dear OE folks,
>
>
> I am still testing this patch. But since the new testing cycle will start soon I am sending this out already.
>
>
> Thanks,
>
> Paul
>
> 8<-------------------------------------------------------------------->8
> Date: Thu, 7 Oct 2010 13:43:58 +0200
>
> Since two or three days I am not able to build `gtk+_2.20.1.bb` anymore. I tried to revert to `gtk+.inc` 9730a2 [1] with
>
> git checkout 9730a28e669931fee601756e949bb210999b4b81 recipes/gtk+/gtk+.inc
>
> but it did not help. I do still get the same error.
>
> | /oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/bin/g-ir-scanner --add-include-path=../gdk-pixbuf --namespace=Gdk --nsversion=2.0 --libtool="/bin/sh ../i686-linux-libtool" --include=Gio-2.0 --include=GdkPixbuf-2.0 --include=Pango-1.0 --library=libgdk-x11-2.0.la --strip-prefix=Gdk --add-include-path=../gdk-pixbuf -DG_LOG_DOMAIN=\"Gdk\" -DGDK_COMPILATION -I.. -I../gdk -I../gdk-pixbuf -DG_DISABLE_CAST_CHECKS -pthread -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/glib-2.0 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/lib/glib-2.0/include -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/pango-1.0 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/cairo -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/pixman-1 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/freetype2 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/libpng12 -I/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/include/gio-unix-2.0/ gdk.h gdkapplaunchcontext.h gdkcairo.h gdkcolor.h gdkcursor.h gdkdisplay.h gdkdisplaymanager.h gdkdnd.h gdkdrawable.h gdkevents.h gdkfont.h gdkgc.h gdki18n.h gdkimage.h gdkinput.h gdkkeys.h gdkkeysyms.h gdkpango.h gdkpixbuf.h gdkpixmap.h gdkprivate.h gdkproperty.h gdkregion.h gdkrgb.h gdkscreen.h gdkselection.h gdkspawn.h gdktestutils.h gdktypes.h gdkvisual.h gdkwindow.h gdk.c gdkapplaunchcontext.c gdkcairo.c gdkcolor.c gdkcursor.c gdkdisplay.c gdkdisplaymanager.c gdkdnd.c gdkdraw.c gdkevents.c gdkfont.c gdkgc.c gdkglobals.c gdkimage.c gdkkeys.c gdkkeyuni.c gdkoffscreenwindow.c gdkpango.c gdkpixbuf-drawable.c gdkpixbuf-render.c gdkpixmap.c gdkpolyreg-generic.c gdkrectangle.c gdkregion-generic.c gdkrgb.c gdkscreen.c gdkselection.c gdkvisual.c gdkwindow.c gdkwindowimpl.c gdkenumtypes.c gdkenumtypes.h x11/checksettings.c x11/gdkapplaunchcontext-x11.c x11/gdkasync.c x11/gdkcolor-x11.c x11/gdkcursor-x11.c x11/gdkdisplay-x11.c x11/gdkdnd-x11.c x11/gdkdrawable-x11.c x11/gdkevents-x11.c x11/gdkfont-x11.c x11/gdkgc-x11.c x11/gdkgeometry-x11.c x11/gdkglobals-x11.c x11/gdkim-x11.c x11/gdkimage-x11.c x11/gdkinput-none.c x11/gdkinput-x11.c x11/gdkinput-xfree.c x11/gdkinput.c x11/gdkkeys-x11.c x11/gdkmain-x11.c x11/gdkpixmap-x11.c x11/gdkproperty-x11.c x11/gdkscreen-x11.c x11/gdkselection-x11.c x11/gdksettings.c x11/gdkspawn-x11.c x11/gdktestutils-x11.c x11/gdkvisual-x11.c x11/gdkwindow-x11.c x11/gdkxftdefaults.c x11/gdkxid.c x11/xsettings-client.c x11/xsettings-common.c libgdk-x11-2.0.la Makefile --output Gdk-2.0.gir
> | Couldn't find include 'Pango-1.0.gir' (search path: ['../gdk-pixbuf', '../gdk-pixbuf', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0', '/usr/share/gir-1.0', '/oe/build-minimal-eglibc/minimal-dev/sysroots/i686-linux/usr/share/gir-1.0'])
>
> `Pango-1.0.gir` is not available in sysroot. But nothing seems to have changed regarding Pango during the last days either.
>
> I am using `minimal` for `MACHINE = "beagleboard"`.
>
> [1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=9730a28e669931fee601756e949bb210999b4b81
>
> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> recipes/gtk+/gtk+_2.20.1.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/recipes/gtk+/gtk+_2.20.1.bb b/recipes/gtk+/gtk+_2.20.1.bb
> index 6ef5e5b..915ccf5 100644
> --- a/recipes/gtk+/gtk+_2.20.1.bb
> +++ b/recipes/gtk+/gtk+_2.20.1.bb
> @@ -19,6 +19,8 @@ ARM_INSTRUCTION_SET = "arm"
> DEPENDS_virtclass-native = "libpng-native atk-native pango-native cairo-native libxrender-native libxext-native libgcrypt-native"
> PROVIDES_virtclass-native = "gdk-pixbuf-csource-native"
>
> +DEPENDS += "pango-native"
> +
> # Enable xkb selectively
> XKBTOGGLE = " --disable-xkb"
> XKBTOGGLE_angstrom = ""
> --
>
I doubt that this is sound.
Your error indicates you are missing includes, so you might need a
DEPENDS on pango, not on pango-native (and maybe pango needs to be
fixed to put its stuff in the right dir or gtk+ to look at the right
place)
Then again I do not see any beagle specific include dirs in your path,
which also greatly surprises me.
And please also don't type things before the --- like "Dear OE folks.
Please do explanations below that line, so if your patch is accepted
people can just do a git am without the need to modify the commit
message.
One other thing:
*if* we need a depend on pango-native, I guess it should go from the
DEPENDS_virtclass-native. Then again I am not that good wrt the
machinery that I can say whether it will not add an additional -native
or so. I recall another issue with that from earlier this week. Then
again I feel the build machinery should not add an addtional -native
suffix to depends etc that already have -native at the end).
frans
^ permalink raw reply
* Re: Need expert's advice - Fast Track Ultra (8R) dropping samples
From: Clemens Ladisch @ 2010-10-08 6:26 UTC (permalink / raw)
To: Felix Homann; +Cc: tiwai, alsa-devel
In-Reply-To: <4CADB077.3060907@showlabor.de>
Felix Homann wrote:
> @Daniel:
> You asked for the output of lsusb. Are you thinking of modifying the
> UA-101 driver yourself? Or something more generic?
I guess he wanted to look for UAC2 descriptors (which this device does
not have).
When (if) the driver has UAC2 implicit feedback support, it's easy to
add a simple quirk that makes the FTU work. (In that case, the UA-101
driver can be merged back, too.)
> Did anyone notice the patch adding mixer support for the FTU devices I
> send on Sept, 25?
Yes, I noticed it.
Regards,
Clemens
^ permalink raw reply
* [Buildroot] [Bug 2683] New: cups does not install correctly to target
From: bugzilla at busybox.net @ 2010-10-08 6:25 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=2683
Summary: cups does not install correctly to target
Product: buildroot
Version: 2010.05
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: marcus.osdoba at googlemail.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0
Created attachment 2587
--> https://bugs.busybox.net/attachment.cgi?id=2587
cups 1.4.4 and autotargets
cups installs its libraries into user/lib64, the attached patch converts to
autotargets and updates to newer version 1.4.4, libraries are installed
correctly, runs well on arm926
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [PATCH] drm/i915: make sure hotpulg is enabled
From: Yuanhan Liu @ 2010-10-08 6:19 UTC (permalink / raw)
To: intel-gfx; +Cc: stable
Make sure hotplug is enabled, or the hotplug interrupt will not be
invoked. And, for sandybridge, the bit definition for hotplug on
SDE is changed. So, update the code to new definition.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378
Cc: stable@kernel.org
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
---
drivers/gpu/drm/i915/i915_irq.c | 19 ++++++++++++++++---
drivers/gpu/drm/i915/i915_reg.h | 4 ++++
drivers/gpu/drm/i915/intel_crt.c | 3 ++-
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 744225e..39a5456 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -310,6 +310,7 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
int ret = IRQ_NONE;
u32 de_iir, gt_iir, de_ier, pch_iir;
+ u32 hotplug_mask;
struct drm_i915_master_private *master_priv;
struct intel_ring_buffer *render_ring = &dev_priv->render_ring;
@@ -325,6 +326,11 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
if (de_iir == 0 && gt_iir == 0 && pch_iir == 0)
goto done;
+ if (HAS_PCH_CPT(dev))
+ hotplug_mask = SDE_HOTPLUG_MASK_CPT;
+ else
+ hotplug_mask = SDE_HOTPLUG_MASK;
+
ret = IRQ_HANDLED;
if (dev->primary->master) {
@@ -367,7 +373,7 @@ irqreturn_t ironlake_irq_handler(struct drm_device *dev)
/* check event from PCH */
if ((de_iir & DE_PCH_EVENT) &&
- (pch_iir & SDE_HOTPLUG_MASK)) {
+ (pch_iir & hotplug_mask)) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
}
@@ -1424,8 +1430,7 @@ static int ironlake_irq_postinstall(struct drm_device *dev)
u32 display_mask = DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE;
u32 render_mask = GT_PIPE_NOTIFY | GT_BSD_USER_INTERRUPT;
- u32 hotplug_mask = SDE_CRT_HOTPLUG | SDE_PORTB_HOTPLUG |
- SDE_PORTC_HOTPLUG | SDE_PORTD_HOTPLUG;
+ u32 hotplug_mask;
dev_priv->irq_mask_reg = ~display_mask;
dev_priv->de_irq_enable_reg = display_mask | DE_PIPEA_VBLANK | DE_PIPEB_VBLANK;
@@ -1450,6 +1455,14 @@ static int ironlake_irq_postinstall(struct drm_device *dev)
I915_WRITE(GTIER, dev_priv->gt_irq_enable_reg);
(void) I915_READ(GTIER);
+ if (HAS_PCH_CPT(dev)) {
+ hotplug_mask = SDE_CRT_HOTPLUG_CPT | SDE_PORTB_HOTPLUG_CPT |
+ SDE_PORTC_HOTPLUG_CPT | SDE_PORTD_HOTPLUG_CPT ;
+ } else {
+ hotplug_mask = SDE_CRT_HOTPLUG | SDE_PORTB_HOTPLUG |
+ SDE_PORTC_HOTPLUG | SDE_PORTD_HOTPLUG;
+ }
+
dev_priv->pch_irq_mask_reg = ~hotplug_mask;
dev_priv->pch_irq_enable_reg = hotplug_mask;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4f5e155..412b38a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2551,6 +2551,10 @@
#define SDE_PORTD_HOTPLUG_CPT (1 << 23)
#define SDE_PORTC_HOTPLUG_CPT (1 << 22)
#define SDE_PORTB_HOTPLUG_CPT (1 << 21)
+#define SDE_HOTPLUG_MASK_CPT (SDE_CRT_HOTPLUG_CPT | \
+ SDE_PORTD_HOTPLUG_CPT | \
+ SDE_PORTC_HOTPLUG_CPT | \
+ SDE_PORTB_HOTPLUG_CPT)
#define SDEISR 0xc4000
#define SDEIMR 0xc4004
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 197d4f3..0f950e7 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -191,7 +191,8 @@ static bool intel_ironlake_crt_detect_hotplug(struct drm_connector *connector)
DRM_DEBUG_KMS("timed out waiting for FORCE_TRIGGER");
if (turn_off_dac) {
- I915_WRITE(PCH_ADPA, temp);
+ /* Make sure hotplug is enabled */
+ I915_WRITE(PCH_ADPA, temp | ADPA_CRT_HOTPLUG_ENABLE);
(void)I915_READ(PCH_ADPA);
}
--
1.7.2.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.