* Re: [PATCH v6 0/3] input: Add support for ECI (multimedia) accessories
From: Dmitry Torokhov @ 2011-02-02 6:21 UTC (permalink / raw)
To: Tapio Vihuri
Cc: peter.ujfalusi, randy.dunlap, linux-kernel, alsa-devel,
ilkka.koskinen, samu.p.onkalo
In-Reply-To: <1296552761.4168.40.camel@dell>
On Tue, Feb 01, 2011 at 11:32:41AM +0200, Tapio Vihuri wrote:
> On Tue, 2011-02-01 at 00:58 -0800, ext Dmitry Torokhov wrote:
> > Hi Tapio,
> >
> > On Mon, Jan 31, 2011 at 04:03:51PM +0200, tapio.vihuri@nokia.com wrote:
> > >
> > > This patch set introduce Multimedia Headset Accessory support for
> > > Nokia phones. Technically those are known as ECI (Enhancement Control Interface)
> > >
> > > If headset has many buttons, like play, vol+, vol- etc. then it is propably ECI
> > > accessory.
> > >
> > > Among several buttons ECI accessories contains memory for storing several
> > > parameters.
> > >
> > > This ECI input driver provides the following features:
> > > - reading ECI configuration memory
> > > - ECI buttons as input events
> > >
> > > Drive is constructed as follows:
> > > - ECI accessory input driver deals with headset accessory
> > > - ECI bus control driver deals the HW transfering data to/from headset
> > > - platform data match used HW
> >
> > I finally had a chance to look though the patches more closely and I do
> > not understand why you decided to introduce the platform device in
> > addition to I2C device. You end up with 2 artificially separated bodies of
> > code that are not viable on their own. The ECI module with it's platform
> > device is not usable without the controller; the controller can not be
> > registered without the ECI device initialized; there are ordering
> > issues, both initialization and PM-wise and you are forced to support
> > only one device.
> >
> > Is there going to be an SPI interface as well? If not then fold it all
> > together and have I2C device as the only device involved. If SPI is a
> > possibility then look in drivers such as adxl34x, ad714x and others that
> > are split into core module and bus interface implementations.
> >
> > Thanks.
> >
>
> Hi Dmitry
>
> Thank you for reviewing.
>
> The reasoning for separating driver to the two parts is having both
> common and different hardware.
>
> The ECI input, as platform device is common part and only dealing with
> the accessory HW (meaning the headset accessory).
> This is standardiced part of system, where specification guarantee HW
> behaving same way accross several headset accessories.
> The accessory is plugged to the terminal using four pin AV-cable, much
> same way as USB mouse.
> I just didn't see need to introduce new bus type for one wire ECI data
> link, hence platform device.
>
> The ECI controller, as I2C device is the variable part of the system.
> In this case it's microcontroller in I2C bus, but there are other
> versions too.
> There is no specification about these controller's internals, and those
> are quite different.
> It is also possible to use other buses too for connecting controller to
> terminal, like SPI.
>
> The idea was that if ECI is used in device, just take ECI input driver
> and select the ECI controller which is used in the platform.
>
> And as long as the ECI controller driver use the same interface to ECI
> input driver, evetrything works OK.
> This allows also dynamic selection of used control device. I mean we can
> compile several ECI controllers as modules and detect the HW at
> initialization.
>
> I use the ad714x as example, but I can take second look on that too.
>
> Please let me know if this is making sense.
Tapio,
I understand that ECI accessory is the standard part that can be attached
to several controllers, it still does not explain the need for the
platform device.
If ECI accessory is the only device that uses the interface you
specified then write a module containing that core functionality, with a
function to instantiate an instance of the accessory and have controller
drivers call this function as part of their bind procedure (i.e. do what
adxl34x and company are doing).
If there could be other accessories utilizing the same interface then
creating a new bus is the only viable option.
Thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 0/3] input: Add support for ECI (multimedia) accessories
From: Dmitry Torokhov @ 2011-02-02 6:21 UTC (permalink / raw)
To: Tapio Vihuri
Cc: randy.dunlap, alsa-devel, samu.p.onkalo, peter.ujfalusi,
linux-kernel, ilkka.koskinen
In-Reply-To: <1296552761.4168.40.camel@dell>
On Tue, Feb 01, 2011 at 11:32:41AM +0200, Tapio Vihuri wrote:
> On Tue, 2011-02-01 at 00:58 -0800, ext Dmitry Torokhov wrote:
> > Hi Tapio,
> >
> > On Mon, Jan 31, 2011 at 04:03:51PM +0200, tapio.vihuri@nokia.com wrote:
> > >
> > > This patch set introduce Multimedia Headset Accessory support for
> > > Nokia phones. Technically those are known as ECI (Enhancement Control Interface)
> > >
> > > If headset has many buttons, like play, vol+, vol- etc. then it is propably ECI
> > > accessory.
> > >
> > > Among several buttons ECI accessories contains memory for storing several
> > > parameters.
> > >
> > > This ECI input driver provides the following features:
> > > - reading ECI configuration memory
> > > - ECI buttons as input events
> > >
> > > Drive is constructed as follows:
> > > - ECI accessory input driver deals with headset accessory
> > > - ECI bus control driver deals the HW transfering data to/from headset
> > > - platform data match used HW
> >
> > I finally had a chance to look though the patches more closely and I do
> > not understand why you decided to introduce the platform device in
> > addition to I2C device. You end up with 2 artificially separated bodies of
> > code that are not viable on their own. The ECI module with it's platform
> > device is not usable without the controller; the controller can not be
> > registered without the ECI device initialized; there are ordering
> > issues, both initialization and PM-wise and you are forced to support
> > only one device.
> >
> > Is there going to be an SPI interface as well? If not then fold it all
> > together and have I2C device as the only device involved. If SPI is a
> > possibility then look in drivers such as adxl34x, ad714x and others that
> > are split into core module and bus interface implementations.
> >
> > Thanks.
> >
>
> Hi Dmitry
>
> Thank you for reviewing.
>
> The reasoning for separating driver to the two parts is having both
> common and different hardware.
>
> The ECI input, as platform device is common part and only dealing with
> the accessory HW (meaning the headset accessory).
> This is standardiced part of system, where specification guarantee HW
> behaving same way accross several headset accessories.
> The accessory is plugged to the terminal using four pin AV-cable, much
> same way as USB mouse.
> I just didn't see need to introduce new bus type for one wire ECI data
> link, hence platform device.
>
> The ECI controller, as I2C device is the variable part of the system.
> In this case it's microcontroller in I2C bus, but there are other
> versions too.
> There is no specification about these controller's internals, and those
> are quite different.
> It is also possible to use other buses too for connecting controller to
> terminal, like SPI.
>
> The idea was that if ECI is used in device, just take ECI input driver
> and select the ECI controller which is used in the platform.
>
> And as long as the ECI controller driver use the same interface to ECI
> input driver, evetrything works OK.
> This allows also dynamic selection of used control device. I mean we can
> compile several ECI controllers as modules and detect the HW at
> initialization.
>
> I use the ad714x as example, but I can take second look on that too.
>
> Please let me know if this is making sense.
Tapio,
I understand that ECI accessory is the standard part that can be attached
to several controllers, it still does not explain the need for the
platform device.
If ECI accessory is the only device that uses the interface you
specified then write a module containing that core functionality, with a
function to instantiate an instance of the accessory and have controller
drivers call this function as part of their bind procedure (i.e. do what
adxl34x and company are doing).
If there could be other accessories utilizing the same interface then
creating a new bus is the only viable option.
Thank you.
--
Dmitry
^ permalink raw reply
* Re: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
From: Grant Likely @ 2011-02-02 6:21 UTC (permalink / raw)
To: John Linn
Cc: nicolas.pitre, Russell King, Catalin Marinas, devicetree-discuss,
linux-kernel, buytenh, Olof Johansson, linux-arm-kernel
In-Reply-To: <c55eb92d-bca0-4047-bbf9-7d532e37154d@VA3EHSMHS029.ehs.local>
[restored cc: list]
On Tue, Feb 01, 2011 at 08:11:15AM -0700, John Linn wrote:
> OK, I see your changes don't really help the problem with device
> trees up higher.
>
> The problem is that in setup_machine_fdt the kernel can't get to the
> memory where the device tree is located if it's up higher.
No, there is another patch to solve that problem from Rob Herring.
I've not yet picked it up into my tree, but I will be doing so soon.
For now the dtb needs to be located inside the first 16k of ram.
However, it can no longer be based at 0 either. I discovered that if
the dt is based at zero, then the kernel is unable to tell the
different between no atags/dtb passed and a dtb passed at physical
address 0. At the very least it needs to be offset about 16 bytes.
Since it is common to put atags at address 0x100, it is also
reasonable to use 0x100 as the dtb base address too.
This problem doesn't exist for machines with ram based at physical
address != 0.
Sorry I wasn't clear when I posted this. There is still a bit of flux
to get the interface correct and I accidentally glossed over this
detail.
> The new stuff you added doesn't run early enough to take care of this problem.
The problem I was trying to solve is that I was seeing device tree
corruption later in the boot process, but it now seems that I might
have misdiagnosed it. I'm still investigation, but I may end up
reverting the memblock_reserve() change.
>
> I probably should have reviewed the patches instead of testing as I
> would have realized that.
>
> I'm looking to see if I can understand how to help the problem.
>
> Should I really just respond to the mailing list instead of this
> back channel? I don't know good behavior from bad sometimes.
Yes, please feel totally free to respond on the mailing list (I went
ahead and restored the cc list on this reply). Just remember to
bottom post when replying on-list.
g.
>
> > -----Original Message-----
> > From: John Linn
> > Sent: Monday, January 31, 2011 5:53 PM
> > To: John Linn; 'Grant Likely'
> > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> >
> > Weird, got it to work with dtb at 0x1000, but not anywhere else. Have tried 0x1000000 and 0x600000
> > without success.
> >
> > Seems to be stopped in exceptions when I look at PC, haven't tried to debug yet, but looks like the
> > same problem to me.
> >
> > Did you have luck with your testing, maybe I'm doing something wrong.
> >
> > > -----Original Message-----
> > > From: John Linn
> > > Sent: Monday, January 31, 2011 5:28 PM
> > > To: John Linn; 'Grant Likely'
> > > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > >
> > > You forgot to tell me that I can no longer have a device tree at address 0 which was previously
> > > working.
> > >
> > > That new check for a value of 0 for the address make it's not work anymore.
> > >
> > > Is there a reason for that? Seems overkill since there's a magic value already. Maybe someone made
> > > you add that.
> > >
> > > Anyway, now it's starting to work again after I hacked out that check. I'll put it back in and test
> > at
> > > non-zero locations.
> > >
> > >
> > > > -----Original Message-----
> > > > From: John Linn
> > > > Sent: Monday, January 31, 2011 4:50 PM
> > > > To: 'Grant Likely'
> > > > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > >
> > > > Very odd, it's not finding the device tree at all when it boots.
> > > >
> > > > Have you seen anything like that?
> > > >
> > > > Still debugging it.
> > > >
> > > > > -----Original Message-----
> > > > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> > > > > Sent: Monday, January 31, 2011 2:58 PM
> > > > > To: John Linn
> > > > > Subject: Re: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > >
> > > > > On Mon, Jan 31, 2011 at 2:42 PM, John Linn <John.Linn@xilinx.com> wrote:
> > > > > >> -----Original Message-----
> > > > > >> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> > > > > >> Sent: Monday, January 31, 2011 2:11 PM
> > > > > >> To: John Linn
> > > > > >> Subject: Re: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > > >>
> > > > > >> On Mon, Jan 31, 2011 at 2:08 PM, John Linn <John.Linn@xilinx.com> wrote:
> > > > > >> > I'm trying to think what's the easiest way for me to retest.
> > > > > >> >
> > > > > >> > I have a branch with 2.6.38-rc1 then your tree merged, then a couple commits of my own on
> > > top.
> > > > > >> >
> > > > > >> > Are these all in your tree?
> > > > > >>
> > > > > >> If you're based on devicetree/arm, then you should be able to just
> > > > > >> merge it again to get the changes. I haven't rebased that branch. In
> > > > > >> fact, the top commit on devicetree/arm will show you the exact diff
> > > > > >> between this series and the previous version.
> > > > > >
> > > > > > Unfortunately moving to 2.6.38-rc2 breaks some stuff. I was surprised but there's still quite
> > a
> > > > bit
> > > > > > of change from rc1 to rc2.
> > > > > >
> > > > > > Still trying to see what all is broken. They moved serial drivers under tty for one thing.
> > > > >
> > > > > You could also directly apply the patches on top of 2.6.38-rc1. That
> > > > > should work too.
> > > > >
> > > > > g.
> > > > >
> > > > > >
> > > > > > -- John
> > > > > >
> > > > > >>
> > > > > >> > Should I retest the whole set of v2 patches or just the one the one that was problem?
> > > > > >>
> > > > > >> The whole tree.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> g.
> > > > > >>
> > > > > >> >
> > > > > >> >> -----Original Message-----
> > > > > >> >> From: Grant Likely [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> > > > > >> >> Sent: Monday, January 31, 2011 2:04 PM
> > > > > >> >> To: nicolas.pitre@linaro.org; Russell King; Catalin Marinas; devicetree-
> > > > > discuss@lists.ozlabs.org;
> > > > > >> >> linux-kernel@vger.kernel.org; buytenh@wantstofly.org; Olof Johansson; John Linn; linux-
> > arm-
> > > > > >> >> kernel@lists.infradead.org
> > > > > >> >> Subject: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > > >> >>
> > > > > >> >> If a dtb is passed to the kernel then the kernel needs to iterate
> > > > > >> >> through compiled-in mdescs looking for one that matches and move the
> > > > > >> >> dtb data to a safe location before it gets accidentally overwritten by
> > > > > >> >> the kernel.
> > > > > >> >>
> > > > > >> >> This patch creates a new function, setup_machine_fdt() which is
> > > > > >> >> analogous to the setup_machine_atags() created in the previous patch.
> > > > > >> >> It does all the early setup needed to use a device tree machine
> > > > > >> >> description. It also creates arm_unflatten_device_tree() which copies
> > > > > >> >> the dtb into an allocated buffer and unflattens it into the live-tree
> > > > > >> >> representation.
> > > > > >> >>
> > > > > >> >> v2: Changed to save the dtb by copying into an allocated buffer.
> > > > > >> >> - Since the dtb will very likely be passed in the first 16k of ram
> > > > > >> >> where the interrupt vectors live, memblock_reserve() is
> > > > > >> >> insufficient to protect the dtb data.
> > > > > >> >> [based on work originally written by Jeremy Kerr <jeremy.kerr@canonical.com>]
> > > > > >> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > > > >> >> ---
> > > > > >> >> arch/arm/include/asm/mach/arch.h | 2 +
> > > > > >> >> arch/arm/include/asm/prom.h | 11 +++++
> > > > > >> >> arch/arm/include/asm/setup.h | 1
> > > > > >> >> arch/arm/kernel/devtree.c | 87 ++++++++++++++++++++++++++++++++++++++
> > > > > >> >> arch/arm/kernel/setup.c | 10 +++-
> > > > > >> >> arch/arm/mm/init.c | 8 +++
> > > > > >> >> 6 files changed, 117 insertions(+), 2 deletions(-)
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> > > > > >> >> index 3a0893a..2ed24e7 100644
> > > > > >> >> --- a/arch/arm/include/asm/mach/arch.h
> > > > > >> >> +++ b/arch/arm/include/asm/mach/arch.h
> > > > > >> >> @@ -22,6 +22,8 @@ struct machine_desc {
> > > > > >> >> unsigned int nr; /* architecture number */
> > > > > >> >> const char *name; /* architecture name */
> > > > > >> >> unsigned long boot_params; /* tagged list */
> > > > > >> >> + const char **dt_compat; /* array of device tree
> > > > > >> >> + * 'compatible' strings */
> > > > > >> >>
> > > > > >> >> unsigned int nr_irqs; /* number of IRQs */
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > > > > >> >> index 8f1037f..6ba62a8 100644
> > > > > >> >> --- a/arch/arm/include/asm/prom.h
> > > > > >> >> +++ b/arch/arm/include/asm/prom.h
> > > > > >> >> @@ -21,5 +21,16 @@ static inline void irq_dispose_mapping(unsigned int virq)
> > > > > >> >> return;
> > > > > >> >> }
> > > > > >> >>
> > > > > >> >> +extern void arm_unflatten_device_tree(void);
> > > > > >> >> +extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > > > > >> >> +
> > > > > >> >> +#else /* CONFIG_OF */
> > > > > >> >> +
> > > > > >> >> +static void arm_unflatten_device_tree(void) { }
> > > > > >> >> +static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> > > > > >> >> +{
> > > > > >> >> + return NULL;
> > > > > >> >> +}
> > > > > >> >> +
> > > > > >> >> #endif /* CONFIG_OF */
> > > > > >> >> #endif /* ASMARM_PROM_H */
> > > > > >> >> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> > > > > >> >> index 06c4d0e..1cec82a 100644
> > > > > >> >> --- a/arch/arm/include/asm/setup.h
> > > > > >> >> +++ b/arch/arm/include/asm/setup.h
> > > > > >> >> @@ -222,6 +222,7 @@ extern struct meminfo meminfo;
> > > > > >> >> #define bank_phys_size(bank) (bank)->size
> > > > > >> >>
> > > > > >> >> extern int arm_add_memory(unsigned long start, unsigned long size);
> > > > > >> >> +extern char cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >>
> > > > > >> >> #endif /* __KERNEL__ */
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > > > > >> >> index ac48da2..07b75bb 100644
> > > > > >> >> --- a/arch/arm/kernel/devtree.c
> > > > > >> >> +++ b/arch/arm/kernel/devtree.c
> > > > > >> >> @@ -21,6 +21,7 @@
> > > > > >> >>
> > > > > >> >> #include <asm/setup.h>
> > > > > >> >> #include <asm/page.h>
> > > > > >> >> +#include <asm/mach/arch.h>
> > > > > >> >>
> > > > > >> >> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> > > > > >> >> {
> > > > > >> >> @@ -45,3 +46,89 @@ unsigned int irq_create_of_mapping(struct device_node *controller,
> > > > > >> >> return intspec[0];
> > > > > >> >> }
> > > > > >> >> EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> > > > > >> >> +
> > > > > >> >> +extern struct machine_desc __arch_info_begin, __arch_info_end;
> > > > > >> >> +
> > > > > >> >> +/**
> > > > > >> >> + * arm_unflatten_device_tree - Copy dtb into a safe area and unflatten it.
> > > > > >> >> + *
> > > > > >> >> + * Copies the dtb out of initial memory and into an allocated block so that
> > > > > >> >> + * it doesn't get overwritten by the kernel and then unflatten it into the
> > > > > >> >> + * live tree representation.
> > > > > >> >> + */
> > > > > >> >> +void __init arm_unflatten_device_tree(void)
> > > > > >> >> +{
> > > > > >> >> + struct boot_param_header *devtree;
> > > > > >> >> + u32 dtb_size;
> > > > > >> >> +
> > > > > >> >> + if (!initial_boot_params)
> > > > > >> >> + return;
> > > > > >> >> +
> > > > > >> >> + /* Save the dtb to an allocated buffer */
> > > > > >> >> + dtb_size = be32_to_cpu(initial_boot_params->totalsize);
> > > > > >> >> + devtree = early_init_dt_alloc_memory_arch(dtb_size, SZ_4K);
> > > > > >> >> + if (!devtree) {
> > > > > >> >> + printk("Unable to allocate memory for device tree\n");
> > > > > >> >> + while(1);
> > > > > >> >> + }
> > > > > >> >> + pr_info("relocating device tree from 0x%p to 0x%p, length 0x%x\n",
> > > > > >> >> + initial_boot_params, devtree, dtb_size);
> > > > > >> >> + memmove(devtree, initial_boot_params, dtb_size);
> > > > > >> >> + initial_boot_params = devtree;
> > > > > >> >> +
> > > > > >> >> + unflatten_device_tree();
> > > > > >> >> +}
> > > > > >> >> +
> > > > > >> >> +/**
> > > > > >> >> + * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> > > > > >> >> + * @dt_phys: physical address of dt blob
> > > > > >> >> + *
> > > > > >> >> + * If a dtb was passed to the kernel in r2, then use it to choose the
> > > > > >> >> + * correct machine_desc and to setup the system.
> > > > > >> >> + */
> > > > > >> >> +struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> > > > > >> >> +{
> > > > > >> >> + struct boot_param_header *devtree = phys_to_virt(dt_phys);
> > > > > >> >> + struct machine_desc *mdesc, *mdesc_best = NULL;
> > > > > >> >> + unsigned int score, mdesc_score = ~1;
> > > > > >> >> + unsigned long dt_root;
> > > > > >> >> + const char *model;
> > > > > >> >> +
> > > > > >> >> + /* check device tree validity */
> > > > > >> >> + if (!dt_phys || be32_to_cpu(devtree->magic) != OF_DT_HEADER)
> > > > > >> >> + return NULL;
> > > > > >> >> +
> > > > > >> >> + /* Search the mdescs for the 'best' compatible value match */
> > > > > >> >> + initial_boot_params = devtree;
> > > > > >> >> +
> > > > > >> >> + dt_root = of_get_flat_dt_root();
> > > > > >> >> + for (mdesc = &__arch_info_begin; mdesc < &__arch_info_end; mdesc++) {
> > > > > >> >> + score = of_flat_dt_match(dt_root, mdesc->dt_compat);
> > > > > >> >> + if (score > 0 && score < mdesc_score) {
> > > > > >> >> + mdesc_best = mdesc;
> > > > > >> >> + mdesc_score = score;
> > > > > >> >> + }
> > > > > >> >> + }
> > > > > >> >> + if (!mdesc_best) {
> > > > > >> >> + printk("Machine not supported, unable to continue.\n");
> > > > > >> >> + while (1);
> > > > > >> >> + }
> > > > > >> >> +
> > > > > >> >> + model = of_get_flat_dt_prop(dt_root, "model", NULL);
> > > > > >> >> + if (!model)
> > > > > >> >> + model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
> > > > > >> >> + if (!model)
> > > > > >> >> + model = "<unknown>";
> > > > > >> >> + pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
> > > > > >> >> +
> > > > > >> >> + /* Retrieve various information from the /chosen node */
> > > > > >> >> + of_scan_flat_dt(early_init_dt_scan_chosen, NULL);
> > > > > >> >> + /* Initialize {size,address}-cells info */
> > > > > >> >> + of_scan_flat_dt(early_init_dt_scan_root, NULL);
> > > > > >> >> + /* Setup memory, calling early_init_dt_add_memory_arch */
> > > > > >> >> + of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> > > > > >> >> + /* Save command line for /proc/cmdline */
> > > > > >> >> + strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE);
> > > > > >> >> +
> > > > > >> >> + return mdesc_best;
> > > > > >> >> +}
> > > > > >> >> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > > > >> >> index cbc1836..68e0204 100644
> > > > > >> >> --- a/arch/arm/kernel/setup.c
> > > > > >> >> +++ b/arch/arm/kernel/setup.c
> > > > > >> >> @@ -20,6 +20,7 @@
> > > > > >> >> #include <linux/screen_info.h>
> > > > > >> >> #include <linux/init.h>
> > > > > >> >> #include <linux/kexec.h>
> > > > > >> >> +#include <linux/of_fdt.h>
> > > > > >> >> #include <linux/crash_dump.h>
> > > > > >> >> #include <linux/root_dev.h>
> > > > > >> >> #include <linux/cpu.h>
> > > > > >> >> @@ -42,6 +43,7 @@
> > > > > >> >> #include <asm/cachetype.h>
> > > > > >> >> #include <asm/tlbflush.h>
> > > > > >> >>
> > > > > >> >> +#include <asm/prom.h>
> > > > > >> >> #include <asm/mach/arch.h>
> > > > > >> >> #include <asm/mach/irq.h>
> > > > > >> >> #include <asm/mach/time.h>
> > > > > >> >> @@ -125,7 +127,7 @@ EXPORT_SYMBOL(elf_platform);
> > > > > >> >>
> > > > > >> >> static const char *cpu_name;
> > > > > >> >> static const char *machine_name;
> > > > > >> >> -static char __initdata cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >> +char cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >> struct machine_desc *machine_desc __initdata;
> > > > > >> >>
> > > > > >> >> static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
> > > > > >> >> @@ -838,7 +840,9 @@ void __init setup_arch(char **cmdline_p)
> > > > > >> >> unwind_init();
> > > > > >> >>
> > > > > >> >> setup_processor();
> > > > > >> >> - mdesc = setup_machine_tags(machine_arch_type);
> > > > > >> >> + mdesc = setup_machine_fdt(__atags_pointer);
> > > > > >> >> + if (!mdesc)
> > > > > >> >> + mdesc = setup_machine_tags(machine_arch_type);
> > > > > >> >> machine_desc = mdesc;
> > > > > >> >> machine_name = mdesc->name;
> > > > > >> >>
> > > > > >> >> @@ -859,6 +863,8 @@ void __init setup_arch(char **cmdline_p)
> > > > > >> >> paging_init(mdesc);
> > > > > >> >> request_standard_resources(mdesc);
> > > > > >> >>
> > > > > >> >> + arm_unflatten_device_tree();
> > > > > >> >> +
> > > > > >> >> #ifdef CONFIG_SMP
> > > > > >> >> if (is_smp())
> > > > > >> >> smp_init_cpus();
> > > > > >> >> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > > > > >> >> index 5164069..62ff2e8 100644
> > > > > >> >> --- a/arch/arm/mm/init.c
> > > > > >> >> +++ b/arch/arm/mm/init.c
> > > > > >> >> @@ -71,6 +71,14 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> > > > > >> >>
> > > > > >> >> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
> > > > > >> >>
> > > > > >> >> +#ifdef CONFIG_OF_FLATTREE
> > > > > >> >> +void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> > > > > >> >> +{
> > > > > >> >> + phys_initrd_start = start;
> > > > > >> >> + phys_initrd_size = end - start + 1;
> > > > > >> >> +}
> > > > > >> >> +#endif /* CONFIG_OF_FLATTREE */
> > > > > >> >> +
> > > > > >> >> /*
> > > > > >> >> * This keeps memory configuration data used by a couple memory
> > > > > >> >> * initialization functions, as well as show_mem() for the skipping
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >> > This email and any attachments are intended for the sole use of the named recipient(s) and
> > > > > >> contain(s) confidential information that may be proprietary, privileged or copyrighted under
> > > > > >> applicable law. If you are not the intended recipient, do not read, copy, or forward this
> > email
> > > > > >> message or any attachments. Delete this email message and any attachments immediately.
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Grant Likely, B.Sc., P.Eng.
> > > > > >> Secret Lab Technologies Ltd.
> > > > > >
> > > > > >
> > > > > > This email and any attachments are intended for the sole use of the named recipient(s) and
> > > > > contain(s) confidential information that may be proprietary, privileged or copyrighted under
> > > > > applicable law. If you are not the intended recipient, do not read, copy, or forward this email
> > > > > message or any attachments. Delete this email message and any attachments immediately.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Grant Likely, B.Sc., P.Eng.
> > > > > Secret Lab Technologies Ltd.
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
From: Grant Likely @ 2011-02-02 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c55eb92d-bca0-4047-bbf9-7d532e37154d@VA3EHSMHS029.ehs.local>
[restored cc: list]
On Tue, Feb 01, 2011 at 08:11:15AM -0700, John Linn wrote:
> OK, I see your changes don't really help the problem with device
> trees up higher.
>
> The problem is that in setup_machine_fdt the kernel can't get to the
> memory where the device tree is located if it's up higher.
No, there is another patch to solve that problem from Rob Herring.
I've not yet picked it up into my tree, but I will be doing so soon.
For now the dtb needs to be located inside the first 16k of ram.
However, it can no longer be based at 0 either. I discovered that if
the dt is based at zero, then the kernel is unable to tell the
different between no atags/dtb passed and a dtb passed at physical
address 0. At the very least it needs to be offset about 16 bytes.
Since it is common to put atags at address 0x100, it is also
reasonable to use 0x100 as the dtb base address too.
This problem doesn't exist for machines with ram based at physical
address != 0.
Sorry I wasn't clear when I posted this. There is still a bit of flux
to get the interface correct and I accidentally glossed over this
detail.
> The new stuff you added doesn't run early enough to take care of this problem.
The problem I was trying to solve is that I was seeing device tree
corruption later in the boot process, but it now seems that I might
have misdiagnosed it. I'm still investigation, but I may end up
reverting the memblock_reserve() change.
>
> I probably should have reviewed the patches instead of testing as I
> would have realized that.
>
> I'm looking to see if I can understand how to help the problem.
>
> Should I really just respond to the mailing list instead of this
> back channel? I don't know good behavior from bad sometimes.
Yes, please feel totally free to respond on the mailing list (I went
ahead and restored the cc list on this reply). Just remember to
bottom post when replying on-list.
g.
>
> > -----Original Message-----
> > From: John Linn
> > Sent: Monday, January 31, 2011 5:53 PM
> > To: John Linn; 'Grant Likely'
> > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> >
> > Weird, got it to work with dtb at 0x1000, but not anywhere else. Have tried 0x1000000 and 0x600000
> > without success.
> >
> > Seems to be stopped in exceptions when I look at PC, haven't tried to debug yet, but looks like the
> > same problem to me.
> >
> > Did you have luck with your testing, maybe I'm doing something wrong.
> >
> > > -----Original Message-----
> > > From: John Linn
> > > Sent: Monday, January 31, 2011 5:28 PM
> > > To: John Linn; 'Grant Likely'
> > > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > >
> > > You forgot to tell me that I can no longer have a device tree at address 0 which was previously
> > > working.
> > >
> > > That new check for a value of 0 for the address make it's not work anymore.
> > >
> > > Is there a reason for that? Seems overkill since there's a magic value already. Maybe someone made
> > > you add that.
> > >
> > > Anyway, now it's starting to work again after I hacked out that check. I'll put it back in and test
> > at
> > > non-zero locations.
> > >
> > >
> > > > -----Original Message-----
> > > > From: John Linn
> > > > Sent: Monday, January 31, 2011 4:50 PM
> > > > To: 'Grant Likely'
> > > > Subject: RE: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > >
> > > > Very odd, it's not finding the device tree at all when it boots.
> > > >
> > > > Have you seen anything like that?
> > > >
> > > > Still debugging it.
> > > >
> > > > > -----Original Message-----
> > > > > From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of Grant Likely
> > > > > Sent: Monday, January 31, 2011 2:58 PM
> > > > > To: John Linn
> > > > > Subject: Re: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > >
> > > > > On Mon, Jan 31, 2011 at 2:42 PM, John Linn <John.Linn@xilinx.com> wrote:
> > > > > >> -----Original Message-----
> > > > > >> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of Grant Likely
> > > > > >> Sent: Monday, January 31, 2011 2:11 PM
> > > > > >> To: John Linn
> > > > > >> Subject: Re: FW: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > > >>
> > > > > >> On Mon, Jan 31, 2011 at 2:08 PM, John Linn <John.Linn@xilinx.com> wrote:
> > > > > >> > I'm trying to think what's the easiest way for me to retest.
> > > > > >> >
> > > > > >> > I have a branch with 2.6.38-rc1 then your tree merged, then a couple commits of my own on
> > > top.
> > > > > >> >
> > > > > >> > Are these all in your tree?
> > > > > >>
> > > > > >> If you're based on devicetree/arm, then you should be able to just
> > > > > >> merge it again to get the changes. ?I haven't rebased that branch. ?In
> > > > > >> fact, the top commit on devicetree/arm will show you the exact diff
> > > > > >> between this series and the previous version.
> > > > > >
> > > > > > Unfortunately moving to 2.6.38-rc2 breaks some stuff. I was surprised but there's still quite
> > a
> > > > bit
> > > > > > of change from rc1 to rc2.
> > > > > >
> > > > > > Still trying to see what all is broken. They moved serial drivers under tty for one thing.
> > > > >
> > > > > You could also directly apply the patches on top of 2.6.38-rc1. That
> > > > > should work too.
> > > > >
> > > > > g.
> > > > >
> > > > > >
> > > > > > -- John
> > > > > >
> > > > > >>
> > > > > >> > Should I retest the whole set of v2 patches or just the one the one that was problem?
> > > > > >>
> > > > > >> The whole tree.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> g.
> > > > > >>
> > > > > >> >
> > > > > >> >> -----Original Message-----
> > > > > >> >> From: Grant Likely [mailto:glikely at secretlab.ca] On Behalf Of Grant Likely
> > > > > >> >> Sent: Monday, January 31, 2011 2:04 PM
> > > > > >> >> To: nicolas.pitre at linaro.org; Russell King; Catalin Marinas; devicetree-
> > > > > discuss at lists.ozlabs.org;
> > > > > >> >> linux-kernel at vger.kernel.org; buytenh at wantstofly.org; Olof Johansson; John Linn; linux-
> > arm-
> > > > > >> >> kernel at lists.infradead.org
> > > > > >> >> Subject: [PATCH v2 4/6] arm/dt: probe for platforms via the device tree
> > > > > >> >>
> > > > > >> >> If a dtb is passed to the kernel then the kernel needs to iterate
> > > > > >> >> through compiled-in mdescs looking for one that matches and move the
> > > > > >> >> dtb data to a safe location before it gets accidentally overwritten by
> > > > > >> >> the kernel.
> > > > > >> >>
> > > > > >> >> This patch creates a new function, setup_machine_fdt() which is
> > > > > >> >> analogous to the setup_machine_atags() created in the previous patch.
> > > > > >> >> It does all the early setup needed to use a device tree machine
> > > > > >> >> description. ?It also creates arm_unflatten_device_tree() which copies
> > > > > >> >> the dtb into an allocated buffer and unflattens it into the live-tree
> > > > > >> >> representation.
> > > > > >> >>
> > > > > >> >> v2: Changed to save the dtb by copying into an allocated buffer.
> > > > > >> >> ? ? - Since the dtb will very likely be passed in the first 16k of ram
> > > > > >> >> ? ? ? where the interrupt vectors live, memblock_reserve() is
> > > > > >> >> ? ? ? insufficient to protect the dtb data.
> > > > > >> >> [based on work originally written by Jeremy Kerr <jeremy.kerr@canonical.com>]
> > > > > >> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > > > >> >> ---
> > > > > >> >> ?arch/arm/include/asm/mach/arch.h | ? ?2 +
> > > > > >> >> ?arch/arm/include/asm/prom.h ? ? ?| ? 11 +++++
> > > > > >> >> ?arch/arm/include/asm/setup.h ? ? | ? ?1
> > > > > >> >> ?arch/arm/kernel/devtree.c ? ? ? ?| ? 87 ++++++++++++++++++++++++++++++++++++++
> > > > > >> >> ?arch/arm/kernel/setup.c ? ? ? ? ?| ? 10 +++-
> > > > > >> >> ?arch/arm/mm/init.c ? ? ? ? ? ? ? | ? ?8 +++
> > > > > >> >> ?6 files changed, 117 insertions(+), 2 deletions(-)
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> > > > > >> >> index 3a0893a..2ed24e7 100644
> > > > > >> >> --- a/arch/arm/include/asm/mach/arch.h
> > > > > >> >> +++ b/arch/arm/include/asm/mach/arch.h
> > > > > >> >> @@ -22,6 +22,8 @@ struct machine_desc {
> > > > > >> >> ? ? ? unsigned int ? ? ? ? ? ?nr; ? ? ? ? ? ? /* architecture number ?*/
> > > > > >> >> ? ? ? const char ? ? ? ? ? ? ?*name; ? ? ? ? ?/* architecture name ? ?*/
> > > > > >> >> ? ? ? unsigned long ? ? ? ? ? boot_params; ? ?/* tagged list ? ? ? ? ?*/
> > > > > >> >> + ? ? const char ? ? ? ? ? ? ?**dt_compat; ? ?/* array of device tree
> > > > > >> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?* 'compatible' strings */
> > > > > >> >>
> > > > > >> >> ? ? ? unsigned int ? ? ? ? ? ?nr_irqs; ? ? ? ?/* number of IRQs */
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > > > > >> >> index 8f1037f..6ba62a8 100644
> > > > > >> >> --- a/arch/arm/include/asm/prom.h
> > > > > >> >> +++ b/arch/arm/include/asm/prom.h
> > > > > >> >> @@ -21,5 +21,16 @@ static inline void irq_dispose_mapping(unsigned int virq)
> > > > > >> >> ? ? ? return;
> > > > > >> >> ?}
> > > > > >> >>
> > > > > >> >> +extern void arm_unflatten_device_tree(void);
> > > > > >> >> +extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > > > > >> >> +
> > > > > >> >> +#else /* CONFIG_OF */
> > > > > >> >> +
> > > > > >> >> +static void arm_unflatten_device_tree(void) { }
> > > > > >> >> +static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> > > > > >> >> +{
> > > > > >> >> + ? ? return NULL;
> > > > > >> >> +}
> > > > > >> >> +
> > > > > >> >> ?#endif /* CONFIG_OF */
> > > > > >> >> ?#endif /* ASMARM_PROM_H */
> > > > > >> >> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> > > > > >> >> index 06c4d0e..1cec82a 100644
> > > > > >> >> --- a/arch/arm/include/asm/setup.h
> > > > > >> >> +++ b/arch/arm/include/asm/setup.h
> > > > > >> >> @@ -222,6 +222,7 @@ extern struct meminfo meminfo;
> > > > > >> >> ?#define bank_phys_size(bank) (bank)->size
> > > > > >> >>
> > > > > >> >> ?extern int arm_add_memory(unsigned long start, unsigned long size);
> > > > > >> >> +extern char cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >>
> > > > > >> >> ?#endif ?/* ?__KERNEL__ ?*/
> > > > > >> >>
> > > > > >> >> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > > > > >> >> index ac48da2..07b75bb 100644
> > > > > >> >> --- a/arch/arm/kernel/devtree.c
> > > > > >> >> +++ b/arch/arm/kernel/devtree.c
> > > > > >> >> @@ -21,6 +21,7 @@
> > > > > >> >>
> > > > > >> >> ?#include <asm/setup.h>
> > > > > >> >> ?#include <asm/page.h>
> > > > > >> >> +#include <asm/mach/arch.h>
> > > > > >> >>
> > > > > >> >> ?void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> > > > > >> >> ?{
> > > > > >> >> @@ -45,3 +46,89 @@ unsigned int irq_create_of_mapping(struct device_node *controller,
> > > > > >> >> ? ? ? return intspec[0];
> > > > > >> >> ?}
> > > > > >> >> ?EXPORT_SYMBOL_GPL(irq_create_of_mapping);
> > > > > >> >> +
> > > > > >> >> +extern struct machine_desc __arch_info_begin, __arch_info_end;
> > > > > >> >> +
> > > > > >> >> +/**
> > > > > >> >> + * arm_unflatten_device_tree - Copy dtb into a safe area and unflatten it.
> > > > > >> >> + *
> > > > > >> >> + * Copies the dtb out of initial memory and into an allocated block so that
> > > > > >> >> + * it doesn't get overwritten by the kernel and then unflatten it into the
> > > > > >> >> + * live tree representation.
> > > > > >> >> + */
> > > > > >> >> +void __init arm_unflatten_device_tree(void)
> > > > > >> >> +{
> > > > > >> >> + ? ? struct boot_param_header *devtree;
> > > > > >> >> + ? ? u32 dtb_size;
> > > > > >> >> +
> > > > > >> >> + ? ? if (!initial_boot_params)
> > > > > >> >> + ? ? ? ? ? ? return;
> > > > > >> >> +
> > > > > >> >> + ? ? /* Save the dtb to an allocated buffer */
> > > > > >> >> + ? ? dtb_size = be32_to_cpu(initial_boot_params->totalsize);
> > > > > >> >> + ? ? devtree = early_init_dt_alloc_memory_arch(dtb_size, SZ_4K);
> > > > > >> >> + ? ? if (!devtree) {
> > > > > >> >> + ? ? ? ? ? ? printk("Unable to allocate memory for device tree\n");
> > > > > >> >> + ? ? ? ? ? ? while(1);
> > > > > >> >> + ? ? }
> > > > > >> >> + ? ? pr_info("relocating device tree from 0x%p to 0x%p, length 0x%x\n",
> > > > > >> >> + ? ? ? ? ? ? initial_boot_params, devtree, dtb_size);
> > > > > >> >> + ? ? memmove(devtree, initial_boot_params, dtb_size);
> > > > > >> >> + ? ? initial_boot_params = devtree;
> > > > > >> >> +
> > > > > >> >> + ? ? unflatten_device_tree();
> > > > > >> >> +}
> > > > > >> >> +
> > > > > >> >> +/**
> > > > > >> >> + * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> > > > > >> >> + * @dt_phys: physical address of dt blob
> > > > > >> >> + *
> > > > > >> >> + * If a dtb was passed to the kernel in r2, then use it to choose the
> > > > > >> >> + * correct machine_desc and to setup the system.
> > > > > >> >> + */
> > > > > >> >> +struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> > > > > >> >> +{
> > > > > >> >> + ? ? struct boot_param_header *devtree = phys_to_virt(dt_phys);
> > > > > >> >> + ? ? struct machine_desc *mdesc, *mdesc_best = NULL;
> > > > > >> >> + ? ? unsigned int score, mdesc_score = ~1;
> > > > > >> >> + ? ? unsigned long dt_root;
> > > > > >> >> + ? ? const char *model;
> > > > > >> >> +
> > > > > >> >> + ? ? /* check device tree validity */
> > > > > >> >> + ? ? if (!dt_phys || be32_to_cpu(devtree->magic) != OF_DT_HEADER)
> > > > > >> >> + ? ? ? ? ? ? return NULL;
> > > > > >> >> +
> > > > > >> >> + ? ? /* Search the mdescs for the 'best' compatible value match */
> > > > > >> >> + ? ? initial_boot_params = devtree;
> > > > > >> >> +
> > > > > >> >> + ? ? dt_root = of_get_flat_dt_root();
> > > > > >> >> + ? ? for (mdesc = &__arch_info_begin; mdesc < &__arch_info_end; mdesc++) {
> > > > > >> >> + ? ? ? ? ? ? score = of_flat_dt_match(dt_root, mdesc->dt_compat);
> > > > > >> >> + ? ? ? ? ? ? if (score > 0 && score < mdesc_score) {
> > > > > >> >> + ? ? ? ? ? ? ? ? ? ? mdesc_best = mdesc;
> > > > > >> >> + ? ? ? ? ? ? ? ? ? ? mdesc_score = score;
> > > > > >> >> + ? ? ? ? ? ? }
> > > > > >> >> + ? ? }
> > > > > >> >> + ? ? if (!mdesc_best) {
> > > > > >> >> + ? ? ? ? ? ? printk("Machine not supported, unable to continue.\n");
> > > > > >> >> + ? ? ? ? ? ? while (1);
> > > > > >> >> + ? ? }
> > > > > >> >> +
> > > > > >> >> + ? ? model = of_get_flat_dt_prop(dt_root, "model", NULL);
> > > > > >> >> + ? ? if (!model)
> > > > > >> >> + ? ? ? ? ? ? model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
> > > > > >> >> + ? ? if (!model)
> > > > > >> >> + ? ? ? ? ? ? model = "<unknown>";
> > > > > >> >> + ? ? pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
> > > > > >> >> +
> > > > > >> >> + ? ? /* Retrieve various information from the /chosen node */
> > > > > >> >> + ? ? of_scan_flat_dt(early_init_dt_scan_chosen, NULL);
> > > > > >> >> + ? ? /* Initialize {size,address}-cells info */
> > > > > >> >> + ? ? of_scan_flat_dt(early_init_dt_scan_root, NULL);
> > > > > >> >> + ? ? /* Setup memory, calling early_init_dt_add_memory_arch */
> > > > > >> >> + ? ? of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> > > > > >> >> + ? ? /* Save command line for /proc/cmdline ?*/
> > > > > >> >> + ? ? strlcpy(boot_command_line, cmd_line, COMMAND_LINE_SIZE);
> > > > > >> >> +
> > > > > >> >> + ? ? return mdesc_best;
> > > > > >> >> +}
> > > > > >> >> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > > > >> >> index cbc1836..68e0204 100644
> > > > > >> >> --- a/arch/arm/kernel/setup.c
> > > > > >> >> +++ b/arch/arm/kernel/setup.c
> > > > > >> >> @@ -20,6 +20,7 @@
> > > > > >> >> ?#include <linux/screen_info.h>
> > > > > >> >> ?#include <linux/init.h>
> > > > > >> >> ?#include <linux/kexec.h>
> > > > > >> >> +#include <linux/of_fdt.h>
> > > > > >> >> ?#include <linux/crash_dump.h>
> > > > > >> >> ?#include <linux/root_dev.h>
> > > > > >> >> ?#include <linux/cpu.h>
> > > > > >> >> @@ -42,6 +43,7 @@
> > > > > >> >> ?#include <asm/cachetype.h>
> > > > > >> >> ?#include <asm/tlbflush.h>
> > > > > >> >>
> > > > > >> >> +#include <asm/prom.h>
> > > > > >> >> ?#include <asm/mach/arch.h>
> > > > > >> >> ?#include <asm/mach/irq.h>
> > > > > >> >> ?#include <asm/mach/time.h>
> > > > > >> >> @@ -125,7 +127,7 @@ EXPORT_SYMBOL(elf_platform);
> > > > > >> >>
> > > > > >> >> ?static const char *cpu_name;
> > > > > >> >> ?static const char *machine_name;
> > > > > >> >> -static char __initdata cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >> +char cmd_line[COMMAND_LINE_SIZE];
> > > > > >> >> ?struct machine_desc *machine_desc __initdata;
> > > > > >> >>
> > > > > >> >> ?static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
> > > > > >> >> @@ -838,7 +840,9 @@ void __init setup_arch(char **cmdline_p)
> > > > > >> >> ? ? ? unwind_init();
> > > > > >> >>
> > > > > >> >> ? ? ? setup_processor();
> > > > > >> >> - ? ? mdesc = setup_machine_tags(machine_arch_type);
> > > > > >> >> + ? ? mdesc = setup_machine_fdt(__atags_pointer);
> > > > > >> >> + ? ? if (!mdesc)
> > > > > >> >> + ? ? ? ? ? ? mdesc = setup_machine_tags(machine_arch_type);
> > > > > >> >> ? ? ? machine_desc = mdesc;
> > > > > >> >> ? ? ? machine_name = mdesc->name;
> > > > > >> >>
> > > > > >> >> @@ -859,6 +863,8 @@ void __init setup_arch(char **cmdline_p)
> > > > > >> >> ? ? ? paging_init(mdesc);
> > > > > >> >> ? ? ? request_standard_resources(mdesc);
> > > > > >> >>
> > > > > >> >> + ? ? arm_unflatten_device_tree();
> > > > > >> >> +
> > > > > >> >> ?#ifdef CONFIG_SMP
> > > > > >> >> ? ? ? if (is_smp())
> > > > > >> >> ? ? ? ? ? ? ? smp_init_cpus();
> > > > > >> >> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > > > > >> >> index 5164069..62ff2e8 100644
> > > > > >> >> --- a/arch/arm/mm/init.c
> > > > > >> >> +++ b/arch/arm/mm/init.c
> > > > > >> >> @@ -71,6 +71,14 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> > > > > >> >>
> > > > > >> >> ?__tagtable(ATAG_INITRD2, parse_tag_initrd2);
> > > > > >> >>
> > > > > >> >> +#ifdef CONFIG_OF_FLATTREE
> > > > > >> >> +void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> > > > > >> >> +{
> > > > > >> >> + ? ? phys_initrd_start = start;
> > > > > >> >> + ? ? phys_initrd_size = end - start + 1;
> > > > > >> >> +}
> > > > > >> >> +#endif /* CONFIG_OF_FLATTREE */
> > > > > >> >> +
> > > > > >> >> ?/*
> > > > > >> >> ? * This keeps memory configuration data used by a couple memory
> > > > > >> >> ? * initialization functions, as well as show_mem() for the skipping
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >> > This email and any attachments are intended for the sole use of the named recipient(s) and
> > > > > >> contain(s) confidential information that may be proprietary, privileged or copyrighted under
> > > > > >> applicable law. If you are not the intended recipient, do not read, copy, or forward this
> > email
> > > > > >> message or any attachments. Delete this email message and any attachments immediately.
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Grant Likely, B.Sc., P.Eng.
> > > > > >> Secret Lab Technologies Ltd.
> > > > > >
> > > > > >
> > > > > > This email and any attachments are intended for the sole use of the named recipient(s) and
> > > > > contain(s) confidential information that may be proprietary, privileged or copyrighted under
> > > > > applicable law. If you are not the intended recipient, do not read, copy, or forward this email
> > > > > message or any attachments. Delete this email message and any attachments immediately.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Grant Likely, B.Sc., P.Eng.
> > > > > Secret Lab Technologies Ltd.
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* RE: RAID 5 - One drive dropped while replacing another
From: Leslie Rhorer @ 2011-02-02 6:20 UTC (permalink / raw)
To: 'Roman Mamedov', 'Bryan Wintermute'; +Cc: linux-raid
In-Reply-To: <20110202043605.593f0c5c@natsu>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Roman Mamedov
> Sent: Tuesday, February 01, 2011 5:36 PM
> To: Bryan Wintermute
> Cc: linux-raid@vger.kernel.org
> Subject: Re: RAID 5 - One drive dropped while replacing another
>
> On Tue, 1 Feb 2011 15:27:50 -0800
> Bryan Wintermute <bryanwintermute@gmail.com> wrote:
>
> > I have a RAID5 setup with 15 drives.
>
> Looks like you got the problem you were so desperately asking for, with
> this
> crazy setup. :(
>
> > Is there anything I can do to get around these bad sectors or force
> mdadm
> > to ignore them to at least complete the recovery?
>
> I suppose the second failed drive is still mostly alive, just has some
> unreadable areas? If so, I suggest that you get another new clean drive,
> and
> while your mdadm array is stopped, copy whatever you can with e.g.
> dd_rescue
> from the semi-dead drive to this new one. Then remove the bad drive from
> the
> system, and start the array with the new drive instead of the bad one.
Before asking this, I would first ask, "How dead is the first dead drive?"
Using dd_rescue on the "dead" drives might recover more data. Or not. It
might be time to drag out the backups.
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 6:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296626748.26937.852.camel@localhost.localdomain>
On Tue, 2011-02-01 at 22:05 -0800, Shirley Ma wrote:
>
> The way I am changing is only when netif queue has stopped, then we
> start to count num_free descriptors to send the signal to wake netif
> queue.
I forgot to mention, the code change I am making is in guest kernel, in
xmit call back only wake up the queue when it's stopped && num_free >=
1/2 *vq->num, I add a new API in virtio_ring.
However vhost signaling reduction is needed as well. The patch I
submitted a while ago showed both CPUs and BW improvement.
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] include/net/genetlink.h: Allow genlmsg_cancel to accept a NULL argument
From: Julia Lawall @ 2011-02-02 6:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, paul.moore, kernel-janitors
In-Reply-To: <20110201.145410.115936566.davem@davemloft.net>
On Tue, 1 Feb 2011, David Miller wrote:
> From: Julia Lawall <julia@diku.dk>
> Date: Fri, 28 Jan 2011 16:43:40 +0100 (CET)
>
> > nlmsg_cancel can accept NULL as its second argument, so for similarity,
> > this patch extends genlmsg_cancel to be able to accept a NULL second
> > argument as well.
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
>
> I did a scan of all of the cases where this interface is used, and
> I cannot find a situation where this capability would even be useful.
>
> The use pattern is always:
>
> hdr = genlmsg_put(skb, ...);
> if (!hdr)
> goto out;
>
> NLA_PUT_*();
> NLA_PUT_*();
> ....
>
> return genlmsg_end(skb, hdr);
>
> nla_put_failure:
> genlmsg_cancel(skb, hdr);
> out:
> return -EWHATEVER;
This pattern occurred in eg:
net/netlabel/netlabel_unlabeled.c
in the function netlbl_unlabel_staticlist_gen and in other netlabel code,
as well as in net/wireless/nl80211.c, but with the function nl80211hdr_put
instead of genlmsg_put. I submitted patches for all of these cases, so
that is perhaps why you don't see them. But someone suggested to change
genlmsg_cancel as well, to be as permissive as nlmsg_cancel.
For nlmsg_cancel, there are two occurrences in
net/netfilter/nf_conntrack_netlink.c where nlmsg_cancel is reachable with
the second argument NULL.
For nlmsg_cancel the ability to accept NULL as a second argument comes
from the fact that it only calls nlmsg_trim, which does nothing if NULL is
the second argument. nlmsg_trim is also called by nla_nest_cancel. There
are many calls to nla_nest_cancel with NULL as the second argument in the
directory net/sched, for example in the function gred_dump in
net/sched/sch_gred.c. net/sched also contains a call to nlmsg_trim with
NULL as the second argument, in the function flow_dump, in
net/sched/cls_flow.c.
The whole thing seems somewhat sloppy. I'm sure that all of the
above-cited occurrences could be rewritten as outlined above to skip over
the cancel/trim function.
julia
^ permalink raw reply
* Re: [PATCH] include/net/genetlink.h: Allow genlmsg_cancel to accept
From: Julia Lawall @ 2011-02-02 6:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, paul.moore, kernel-janitors
In-Reply-To: <20110201.145410.115936566.davem@davemloft.net>
On Tue, 1 Feb 2011, David Miller wrote:
> From: Julia Lawall <julia@diku.dk>
> Date: Fri, 28 Jan 2011 16:43:40 +0100 (CET)
>
> > nlmsg_cancel can accept NULL as its second argument, so for similarity,
> > this patch extends genlmsg_cancel to be able to accept a NULL second
> > argument as well.
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
>
> I did a scan of all of the cases where this interface is used, and
> I cannot find a situation where this capability would even be useful.
>
> The use pattern is always:
>
> hdr = genlmsg_put(skb, ...);
> if (!hdr)
> goto out;
>
> NLA_PUT_*();
> NLA_PUT_*();
> ....
>
> return genlmsg_end(skb, hdr);
>
> nla_put_failure:
> genlmsg_cancel(skb, hdr);
> out:
> return -EWHATEVER;
This pattern occurred in eg:
net/netlabel/netlabel_unlabeled.c
in the function netlbl_unlabel_staticlist_gen and in other netlabel code,
as well as in net/wireless/nl80211.c, but with the function nl80211hdr_put
instead of genlmsg_put. I submitted patches for all of these cases, so
that is perhaps why you don't see them. But someone suggested to change
genlmsg_cancel as well, to be as permissive as nlmsg_cancel.
For nlmsg_cancel, there are two occurrences in
net/netfilter/nf_conntrack_netlink.c where nlmsg_cancel is reachable with
the second argument NULL.
For nlmsg_cancel the ability to accept NULL as a second argument comes
from the fact that it only calls nlmsg_trim, which does nothing if NULL is
the second argument. nlmsg_trim is also called by nla_nest_cancel. There
are many calls to nla_nest_cancel with NULL as the second argument in the
directory net/sched, for example in the function gred_dump in
net/sched/sch_gred.c. net/sched also contains a call to nlmsg_trim with
NULL as the second argument, in the function flow_dump, in
net/sched/cls_flow.c.
The whole thing seems somewhat sloppy. I'm sure that all of the
above-cited occurrences could be rewritten as outlined above to skip over
the cancel/trim function.
julia
^ permalink raw reply
* Re: issue with AD1989A HDA codec and alsamixer
From: Raymond Yau @ 2011-02-02 6:16 UTC (permalink / raw)
To: ALSA Development Mailing List
In-Reply-To: <AANLkTinec0di98dMdyNoANXBoLG_uRJ+NghEyboCuMUa@mail.gmail.com>
2011/2/2 Raymond Yau <superquad.vortex2@gmail.com>
>
>
> 2011/2/1 Vincent Meserette <vmeserette@aldebaran-robotics.com>
>
> Hi all,
>>
>> I am working on a system which includes a connexant AD1989A HDA codec
>> connected to a ATOM processor.
>> I have four microphones connected to the B and C ports of this codec.
>> If I change one of the 3 capture gains present in the alsamixer
>> (Capture, Capture 1 or Capture 3), I can't have any more signal on the
>> B and C ports
>> It seems to be due to the fact that ALSA breaks (for example for the
>> Capture gain) the link between the ADC selector 0 and ADC_0 widgets of
>> the codec, what can be easily seen with codecgraph.
>>
>> Have you ever had this kind of problem?
>> Do you know how can I resolve it ?
>>
>> Many thanks for your asnwers and best regards
>>
>> Vincent
>>
>
> What is the Vendor Id of conexant AD1989A ?
>
> are your codec are using patch_analog.c according to vendor id of the codec
> ?
>
> Looking at the datasheet of ad1988a , ad1988b and ad1989b at analog device
> web site and ad1989a conexant web site
>
> The digital microphone of conexant ad1989a only connect to adc0 in the
> functional block diagram
>
>
If the number of input sources of adc0 of ad1989a is more than those of adc1
and adc2
This may mean that you will need to implement a specific
ad1989a_capture_mixer[] for ad1989a instead of using ad1988_capture_mixer
and
may need to implement ad1989a_pcm_analog_alt_capture for adc1 and adc2
similar to alc880_pcm_analog_alt_capture
^ permalink raw reply
* RE: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
From: Santosh Shilimkar @ 2011-02-02 6:15 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-omap, paul, Benoit Cousson, Rajendra Nayak,
linux-arm-kernel
In-Reply-To: <87aaifmdsg.fsf@ti.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@ti.com]
> Sent: Wednesday, February 02, 2011 6:52 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; b-cousson@ti.com;
> rnayak@ti.com; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_*
> flags instead of values
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > IVAHD and ABE power domain logic state is populated using directly
> > value instead of the capability flags.
> >
> > Fix the same.
>
> Again, has this been fixed in the scripts?
>
> For future reference, It will be helpful to note in the changelog
> that
> this kind of thing has been fixed in the autogen scripts.
>
The power domain scripts was out of sync with code.
And hence its not mentioned.
Benoit has merged the changes from Paul and we will
update this additional change on top of it
Regards,
Santosh
^ permalink raw reply
* [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
From: Santosh Shilimkar @ 2011-02-02 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87aaifmdsg.fsf@ti.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Wednesday, February 02, 2011 6:52 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; paul at pwsan.com; b-cousson at ti.com;
> rnayak at ti.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_*
> flags instead of values
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > IVAHD and ABE power domain logic state is populated using directly
> > value instead of the capability flags.
> >
> > Fix the same.
>
> Again, has this been fixed in the scripts?
>
> For future reference, It will be helpful to note in the changelog
> that
> this kind of thing has been fixed in the autogen scripts.
>
The power domain scripts was out of sync with code.
And hence its not mentioned.
Benoit has merged the changes from Paul and we will
update this additional change on top of it
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v2 13/13] OMAP: hwmod: Removal of macros for data that is obtained from hwmod database
From: ABRAHAM, KISHON VIJAY @ 2011-02-02 6:15 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-omap, alsa-devel, lrg, broonie, paul, charu, shubhrajyoti,
b-cousson, khilman, p-basak2
In-Reply-To: <20110201200713.34fdb4fc.jhnikula@gmail.com>
On Tue, Feb 1, 2011 at 11:37 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
> On Mon, 31 Jan 2011 20:20:37 +0530
> Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
>> Information like base address and DMA channel nubers should no longer
>> be obtained using macros. These information should be obtained from
>> hwmod database. Hence the macros that define the base address are removed.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> Signed-off-by: Charulatha V <charu@ti.com>
>> ---
>> arch/arm/mach-omap1/mcbsp.c | 64 +++++++++++++++---------------
>> arch/arm/plat-omap/include/plat/mcbsp.h | 50 +-----------------------
>> 2 files changed, 33 insertions(+), 81 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
>> index 2b89ebd..d90f649 100644
>> --- a/arch/arm/mach-omap1/mcbsp.c
>> +++ b/arch/arm/mach-omap1/mcbsp.c
>> @@ -83,14 +83,14 @@ struct resource omap7xx_mcbsp_res[][6] = {
>> {
>> {
>> .name = "mpu",
>> - .start = OMAP7XX_MCBSP1_BASE,
>> - .end = OMAP7XX_MCBSP1_BASE + SZ_256,
>> + .start = 0xfffb1000,
>> + .end = 0xfffb10ff,
>
> For these changes I don't see immediate reason as they reduce
> readability.
Maybe I should leave without modifying these resources. The main
purpose of doing this
is to remove macros defined in mcbsp.h so that the client drivers
don't use it directly.
>Is this better to do outside of this set together with a
> patch that adds these into hwmod database etc?
OMAP1 does not have hwmod database.
>
>> -#define AUDIO_MCBSP_DATAWRITE (OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1)
>> -#define AUDIO_MCBSP_DATAREAD (OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1)
>> -
>> -#define AUDIO_MCBSP OMAP_MCBSP1
>> -#define AUDIO_DMA_TX OMAP_DMA_MCBSP1_TX
>> -#define AUDIO_DMA_RX OMAP_DMA_MCBSP1_RX
>> -
>> #else
>>
>> #define OMAP_MCBSP_REG_DRR2 0x00
>> @@ -177,13 +136,6 @@ static struct platform_device omap_mcbsp##port_nr = { \
>> #define OMAP_ST_REG_SFIRCR 0x28
>> #define OMAP_ST_REG_SSELCR 0x2C
>>
>> -#define AUDIO_MCBSP_DATAWRITE (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
>> -#define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
>> -
>> -#define AUDIO_MCBSP OMAP_MCBSP2
>> -#define AUDIO_DMA_TX OMAP24XX_DMA_MCBSP2_TX
>> -#define AUDIO_DMA_RX OMAP24XX_DMA_MCBSP2_RX
>> -
> These looks things that can be removed immediately and independently
> from this set.
ok.
>
> --
> Jarkko
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Intermittent ENOSPC in 2.6.38rc2 (BUG linux/fs/btrfs/inode.c:1759)
From: cwillu @ 2011-02-02 6:15 UTC (permalink / raw)
To: Chris Samuel; +Cc: linux-btrfs
In-Reply-To: <4D48F42F.6020204@csamuel.org>
On Wed, Feb 2, 2011 at 12:05 AM, Chris Samuel <chris@csamuel.org> wrote:
> On 02/02/11 16:41, cwillu wrote:
>
>> Building btrfs from josef's tree seems to clear this up,
>> I was able to build dozens of times without errors.
>
> Interesting, I wonder what fixes it ?
The error was an ENOSPC, which was specifically why josef had me try that tree.
^ permalink raw reply
* [PATCH] adjust suspicious memset in nfsacl_encode()
From: Milton Miller @ 2011-02-02 6:14 UTC (permalink / raw)
To: Chuck Lever, Trond Myklebust
Cc: J. Bruce Fields, Neil Brown, linux-nfs, linux-kernel
commit f61f6da0d53842e849bab7f69e1431bd3de1136d "NFS: Prevent memory
allocation failure in nfsacl_encode()" added a memset whose length was
the size of the pointer. Change this to the size of the pointed struct
that is later passed to posix_acl_init(). The 4 entries that are the
remainder of the parent struct will be set and therefore should not
need zeroing.
Alternatively we could remove the memset as posix_acl_init sets all
fields with storage in struct posix_acl and we won't reference any
implicit padding.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
While I was reviewing changes merged post rc2 I saw this suspicious memset.
diff --git a/fs/nfs_common/nfsacl.c b/fs/nfs_common/nfsacl.c
index 84c27d6..bc6d81b 100644
--- a/fs/nfs_common/nfsacl.c
+++ b/fs/nfs_common/nfsacl.c
@@ -117,7 +117,7 @@ int nfsacl_encode(struct xdr_buf *buf, unsigned int base, struct inode *inode,
* invoked in contexts where a memory allocation failure is
* fatal. Fortunately this fake ACL is small enough to
* construct on the stack. */
- memset(acl2, 0, sizeof(acl2));
+ memset(acl2, 0, sizeof(*acl2));
posix_acl_init(acl2, 4);
/* Insert entries in canonical order: other orders seem
^ permalink raw reply related
* Re: [GIT PULL 0/2] perf/core improvements and fixes
From: Ingo Molnar @ 2011-02-02 6:11 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: linux-kernel, Frederic Weisbecker, Mike Galbraith, Paul Mackerras,
Peter Zijlstra, Stephane Eranian, Tom Zanussi,
Arnaldo Carvalho de Melo
In-Reply-To: <1296581395-30663-1-git-send-email-acme@infradead.org>
* Arnaldo Carvalho de Melo <acme@infradead.org> wrote:
> Hi Ingo,
>
> Please consider pulling from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf/core
>
> Regards,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (2):
> perf tools: Remove verbose build messages for the python binding
> perf tools: Fix up 'make clean' target
>
> tools/perf/Makefile | 16 +++++++++-------
> 1 files changed, 9 insertions(+), 7 deletions(-)
Pulled (the other commits as well), thanks Arnaldo!
Ingo
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 6:05 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110202044002.GB3818@redhat.com>
On Wed, 2011-02-02 at 06:40 +0200, Michael S. Tsirkin wrote:
> ust tweak the parameters with sysfs, you do not have to edit the code:
> echo 64 > /sys/module/vhost_net/parameters/tx_bufs_coalesce
>
> Or in a similar way for tx_packets_coalesce (since we use indirect,
> packets will typically use 1 buffer each).
We should use packets instead of buffers, in indirect case, one packet
has multiple buffers, each packet uses one descriptor from the ring
(default size is 256).
echo 128 > /sys/module/vhost_net/parameters/tx_packets_coalesce
The way I am changing is only when netif queue has stopped, then we
start to count num_free descriptors to send the signal to wake netif
queue.
Shirley
^ permalink raw reply
* RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Santosh Shilimkar @ 2011-02-02 6:05 UTC (permalink / raw)
To: Tony Lindgren, Anand Gadiyar
Cc: Russell King - ARM Linux, linux-arm-kernel, linux-omap,
Keshava Munegowda, Felipe Balbi
In-Reply-To: <20110202011006.GP3358@atomide.com>
> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, February 02, 2011 6:40 AM
> To: Anand Gadiyar
> Cc: Russell King - ARM Linux; linux-arm-kernel@lists.infradead.org;
> linux-omap@vger.kernel.org; Keshava Munegowda; Santosh Shilimkar;
> Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > I believe this fix is fixing your reboot issue, but it's breaking
> > EHCI support on the SDP.
> >
> > The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> > By changing
> >
> > The patch snippet below fixes EHCI on the SDP, but I believe that
> > making this change will reintroduce the "board reboots" issue
> > you originally reported. Could you check and tell me if this
> > is the case?
>
> Hmm sorry looks like I made a typo there. That should be fixed.
>
> > Just curious - is your board a Blaze, or an SDP?
>
> It's a ES1.0 blaze, with the patch below it reboots early
> during the boot. I also have to disable omap_l2_cache_init
> on this board to get it to boot.
>
Do you still get this problem with 'omap_l2_cache_init' ?
As reported earlier, we don't see this issue on ES1.0
SDP.
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Santosh Shilimkar @ 2011-02-02 6:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110202011006.GP3358@atomide.com>
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Wednesday, February 02, 2011 6:40 AM
> To: Anand Gadiyar
> Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org;
> linux-omap at vger.kernel.org; Keshava Munegowda; Santosh Shilimkar;
> Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > I believe this fix is fixing your reboot issue, but it's breaking
> > EHCI support on the SDP.
> >
> > The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> > By changing
> >
> > The patch snippet below fixes EHCI on the SDP, but I believe that
> > making this change will reintroduce the "board reboots" issue
> > you originally reported. Could you check and tell me if this
> > is the case?
>
> Hmm sorry looks like I made a typo there. That should be fixed.
>
> > Just curious - is your board a Blaze, or an SDP?
>
> It's a ES1.0 blaze, with the patch below it reboots early
> during the boot. I also have to disable omap_l2_cache_init
> on this board to get it to boot.
>
Do you still get this problem with 'omap_l2_cache_init' ?
As reported earlier, we don't see this issue on ES1.0
SDP.
^ permalink raw reply
* Re: Intermittent ENOSPC in 2.6.38rc2 (BUG linux/fs/btrfs/inode.c:1759)
From: Chris Samuel @ 2011-02-02 6:05 UTC (permalink / raw)
To: cwillu; +Cc: linux-btrfs
In-Reply-To: <AANLkTimJA+cT7LvtwTuWBroQA5GVv8HvTcGO7g=PGsqw@mail.gmail.com>
On 02/02/11 16:41, cwillu wrote:
> Building btrfs from josef's tree seems to clear this up,
> I was able to build dozens of times without errors.
Interesting, I wonder what fixes it ?
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
^ permalink raw reply
* [ath9k-devel] Weird error messages in logs
From: Mohammed Shafi @ 2011-02-02 6:04 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <AANLkTintLB3muakm75+m35fd5DFN1BMG2jY8_p_ju5ih@mail.gmail.com>
On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov <mar.kolya@gmail.com> wrote:
> Hi.
>
> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
> has latest linux driver. Network operates in 801.11g mode. When client
> uploads to the AP for a long time I get these errors in logs on AP:
>
Hi what card you are using?
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0 ?Attempting
> to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 14 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 24 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 34 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 42 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 45 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 63 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 67 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 78 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 85 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 89 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 94 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 101 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 108 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 113 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 120 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
>
> Transmission seems to die after this.
> Could you please tell me what these messages mean and is it possible
> to fix this issue on ath9k side?
> Thanks!
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply
* Re: BUG at inode.c:150 under 2.6.38rc2 + 9d4ba5: handle errors in btrfs_orphan_cleanup
From: cwillu @ 2011-02-02 6:03 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <AANLkTikhL0j5Hpq2sAN6qT30+KqWzeLB8g46NgxAfSWL@mail.gmail.com>
On Tue, Feb 1, 2011 at 11:37 PM, cwillu <cwillu@cwillu.com> wrote:
> A couple hours after a build finished involving creating and deleting
> a couple snapshots, I got the following BUG. =A0The system locked up
> completely.
>
> This is 2.6.38rc2 with btrfs from josef's master (9d4ba5: =A0Btrfs:
> handle errors in btrfs_orphan_cleanup).
>
> Original screenshot at http://imgur.com/sCinW
> Retyped from that:
>
> kernel BUG at /var/lib/dkms/btrfs/git/build/inode.c:150!
> invalid opcode: 0000 [#1] SMP
> last sysfs file:
> /sys/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/=
sdb/uevent
> CPU 1
> Modules linked in: binfmt_misc ppdev ipt_MASQUERADE iptable_nat nf_na=
t
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
> xt_tcpudd iptable_filter ip_tables x_tables bridge stp
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
> snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device aes_x86_64 snd aes_generic soundcore dm_crypt
> asus_atk0110 lp snd_page_alloc parport raid10 raid456
> async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy
> async_tx raid1 raid0 multipath linear btrfs zlib_deflate libcrc32c
> radeon ttm drm_kms_helper drm usbhid usb_storage hid uas ahci
> i2c_algo_bit r8169 libahci pata_jmicron
>
> Pid: 17930, comm: btrfs-delalloc- Not tainted 2.6.38-020638rc2-generi=
c
> #201101220905 P5Q3/System Product Name
> RIP: 0010:[<ffffffffa0219cf8>] [<ffffffffa0219cf8>]
> insert_inline_extent+0x328/0x330 [btrfs]
> RSP: 0000:ffff88020a17bbf0 =A0EFLAGS: 00010282
> RAX: 00000000ffffffef RBX: 000000000000003f RCX: ffff88020a17a000
> RDX: 0000000000000008 RSI: ffff880000000000 RDI: ffff880185a99c38
> RBP: ffff88020a17bc80 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff88022a433800 R11: ffff88017b096a00 R12: ffff88021bfb7390
> R13: 0000000000000054 R14: 0000000000000200 R15: 0000000000000000
> FS: =A00000000000000000(0000) GS:ffff8800bfc80000(0000) knlGS:0000000=
000000000
> CS: =A00010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007f6b5afdfc68 CR3: 000000021697c000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process btrfs-delalloc- (pid: 17930, threadinfo ffff88020a17a000, tas=
k
> ffff88022b158000)
> Stack:
> =A000000002005b09d8 0000000000000001 ffff88022a433800 0000000000000fd=
5
> =A0ffff88017b096a00 0000000000000001 ffff88022cab3d80 000000000000020=
0
> =A000000000005b09d5 000000000000006c ffff88020a17bc00 00000054a0253ff=
8
> Call Trace:
> =A0[<ffffffffa0219e21>] cow_file_range_inline+0x121/0x190 [btrfs]
> =A0[<ffffffff815a2ffe>] ? mutex_lock+0x1e/0x50
> =A0[<ffffffffa021ffb3>] compress_file_range+0x483/0x5e0 [btrfs]
> =A0[<ffffffffa0220145>] async_cow_start+0x35/0x50 [btrfs]
> =A0[<ffffffffa02419bc>] worker_loop+0x15c/0x5b0 [btrfs]
> =A0[<ffffffffa0241860>] ? worker_loop+0x0/0x5b0 [btrfs]
> =A0[<ffffffff81085147>] kthread+0x97/0xa0
> =A0[<ffffffff8100ce24>] kernel_thread_helper+0x4/0x10
> =A0[<ffffffff810850b0>] ? kthread+0x0/0xa0
> =A0[<ffffffff8100ce20>] ? kernel_thread_helper+0x0/0x10
> Code: f8 03 48 0f af c2 4c 89 ea 48 c1 e0 0c 48 01 f0 4a 8d 34 38 e8
> 0a b4 01 00 83 6b 1c 01 48 8b 7d 98 e8 3d 9e ef e0 e9 fc fe ff ff <0f=
>
> 0b eb fe 0f 1f 40 00 55 48 89 e5 48 83 ec 70 48 89 5d d8 4c
> RIP =A0[<ffffffffa0219cf8>] insert_inline_extent+0x328/0x330 [btrfs]
> =A0RSP <ffff88020a17bbf0>
The crash happened after a few hours idling; last significant
workload was an experiment with my build process abusing the snapshot
facility: a base system was installed to a subvolume via debootstrap,
then 8 snapshots of that state were taken. Things were installed to
those snapshots in parallel, and then everything was rsync'd back to
the master, after which the snapshots were deleted. There wouldn't
have been any syncs, fsyncs or otherwise during the builds (dpkg was
run with libeatmydata, for instance). The original subvolume would
have been ~1gb, and each snapshot grown slightly more than that, so
there would've been ~8gb worth of snapshots being deleted in the
background.
The code in question dates back to the original zlib compression
commit, and the system was running with compess=3Dlzo; perhaps there's
some mismatch there?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Improve mount.ceph.8
From: Chris Dunlop @ 2011-02-02 6:02 UTC (permalink / raw)
To: ceph-devel
Seeing as I was wondering what "rbytes" might be, I guess others might
too...
diff --git a/man/mount.ceph.8 b/man/mount.ceph.8
index d5fe62a..f2cdd86 100644
--- a/man/mount.ceph.8
+++ b/man/mount.ceph.8
@@ -129,12 +129,12 @@ no funky `cat dirname` for stats
rbytes
.IP
-Report rbytes for st_size on directories. Default: on
+Report the recursive size of the directory contents for st_size on directories. Default: on
.PP
norbytes
.IP
-Do not report rbytse for st_size.
+Do not report the recursive size of the directory contents for st_size on directories.
.PP
nocrc
^ permalink raw reply related
* [Query]Using vcxio regulator on 4430sdp
From: archit taneja @ 2011-02-02 11:30 UTC (permalink / raw)
To: linux-omap
Hi,
VCXIO regulator on 4430sdp has consumers like MPU, IVA, and DSI in DSS.
It is enabled at bootloader itself since its required very early.
Currently, the regulator_init_data struct for vcxio in board-4430sdp.c
doesn't show any consumers.
How can I implement regulator_enable/disable calls in my driver for a
consumer of vcxio without disturbing the mpu and iva etc consumers which
don't use regulator api to enable/disable the regulator at all.
Also, is anyone aware why vcxio is tied to DSI in 4430sdp, would it be
possible for some other omap4 board to have a different regulator supply
for DSI?
Thanks,
Archit
^ permalink raw reply
* Re: MWDMA Issue: sda: unknown partition table
From: viresh kumar @ 2011-02-02 5:58 UTC (permalink / raw)
To: Eric D. Mudama
Cc: Viresh Kumar, Tejun Heo, linux-ide@vger.kernel.org, Shiraz HASHIM,
Armando VISCONTI, amitgoel
In-Reply-To: <20110202055527.GD26790@bounceswoosh.org>
On 02/02/2011 11:25 AM, Eric D. Mudama wrote:
>> >Just to get over this doubt, i will try place a small udelay after data is transferred
>> >and before framework is communicated for successful xfer.
> That's a good thing to try, wouldn't be the first time I've heard of
> things like that being required.
I tried this, and still get same error sometimes. I took a 100ms delay.
--
viresh
^ permalink raw reply
* Re: [PATCH 0/2] meta-sugarbay: new layer for Sandy Bridge/Cougar Point
From: Tom Zanussi @ 2011-02-02 5:58 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: poky@yoctoproject.org
In-Reply-To: <AANLkTi=nevskgmtJnSm-x7nyCJF5khmpoiYgeXwxgCgD@mail.gmail.com>
On Tue, 2011-02-01 at 21:52 -0800, Bruce Ashfield wrote:
> On Mon, Jan 31, 2011 at 11:35 PM, Tom Zanussi <tom.zanussi@intel.com> wrote:
> > From: Tom Zanussi <tom.zanussi@intel.com>
> >
> > This layer provides support for the 'Sugar Bay' platform, which
> > consists of the Intel Sandy Bridge processor and the Cougar Point PCH.
> >
> > It also adds a new meta-intel/common directory for sharing commmon
> > code between meta-intel BSPs - for now, it's acting as a kind of
> > 'staging' area for the grub2 and associated live-install changes
> > needed to install from a live image.
>
> Based on where I just merged support for this your kernel bbappend
>
> +KMACHINE_sugarbay = "yocto/standard/sugarbay"
>
> will need to be:
>
> +KMACHINE_sugarbay = "yocto/standard/common-pc-64/sugarbay"
>
> I'll cc you on my SRCREV change so you'll know to make this update.
>
Thanks, Bruce. I'll make the changes then and retest as well...
Tom
> Cheers,
>
> Bruce
>
>
> >
> > Thanks,
> >
> > Tom
> >
> > Pull URL: git://git.pokylinux.org/meta-intel/tzanussi/sugarbay
> > Branch: tzanussi/sugarbay
> > Browse:
> > http://git.pokylinux.org/cgit.cgi/meta-intel/log/?h=tzanussi/sugarbay
> >
> > Tom Zanussi (2):
> > meta-intel: add a /common dir with grub2/live-install changes
> > meta-sugarbay: new layer for Sandy Bridge/Cougar Point systems
> >
> > common/recipes-bsp/grub/grub-1.98/40_custom | 9 +
> > .../grub/grub-1.98/grub-install.in.patch | 13 ++
> > .../grub/grub-1.98/uninit-shdr-fix.patch | 31 ++++
> > common/recipes-bsp/grub/grub_1.98.bb | 45 +++++
> > .../initramfs-live-install/init-install.sh | 188 ++++++++++++++++++++
> > .../initramfs-live-install_1.0.bbappend | 2 +
> > meta-sugarbay/COPYING.MIT | 17 ++
> > meta-sugarbay/README | 84 +++++++++
> > meta-sugarbay/conf/layer.conf | 12 ++
> > meta-sugarbay/conf/machine/sugarbay.conf | 57 ++++++
> > .../formfactor/formfactor/sugarbay/machconfig | 3 +
> > .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 3 +
> > .../xserver-xf86-config/sugarbay/xorg.conf | 26 +++
> > .../xorg-xserver/xserver-xf86-config_0.1.bbappend | 3 +
> > .../xserver-xf86-dri-lite_1.9.3.bbappend | 1 +
> > .../recipes-kernel/linux/linux-yocto_git.bbappend | 5 +
> > 16 files changed, 499 insertions(+), 0 deletions(-)
> > create mode 100755 common/recipes-bsp/grub/grub-1.98/40_custom
> > create mode 100644 common/recipes-bsp/grub/grub-1.98/grub-install.in.patch
> > create mode 100644 common/recipes-bsp/grub/grub-1.98/uninit-shdr-fix.patch
> > create mode 100644 common/recipes-bsp/grub/grub_1.98.bb
> > create mode 100644 common/recipes-core/initrdscripts/initramfs-live-install/init-install.sh
> > create mode 100644 common/recipes-core/initrdscripts/initramfs-live-install_1.0.bbappend
> > create mode 100644 meta-sugarbay/COPYING.MIT
> > create mode 100644 meta-sugarbay/README
> > create mode 100644 meta-sugarbay/binary/.gitignore
> > create mode 100644 meta-sugarbay/conf/layer.conf
> > create mode 100644 meta-sugarbay/conf/machine/sugarbay.conf
> > create mode 100644 meta-sugarbay/recipes-bsp/formfactor/formfactor/sugarbay/machconfig
> > create mode 100644 meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
> > create mode 100644 meta-sugarbay/recipes-graphics/xorg-xserver/xserver-xf86-config/sugarbay/xorg.conf
> > create mode 100644 meta-sugarbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> > create mode 100644 meta-sugarbay/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.9.3.bbappend
> > create mode 100644 meta-sugarbay/recipes-kernel/linux/linux-yocto_git.bbappend
> >
> > _______________________________________________
> > poky mailing list
> > poky@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/poky
> >
>
>
>
^ permalink raw reply
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.