On Tue, Jan 10, 2012 at 11:25 AM, Mike Frysinger wrote:
> On Monday 09 January 2012 16:25:41 Tom Rini wrote:
>> On Mon, Jan 9, 2012 at 2:23 PM, Tom Rini wrote:
>> > On Mon, Jan 9, 2012 at 2:21 PM, Mike Frysinger wrote:
>> >> On Monday 09 January 2012 14:41:07 Scott Wood wrote:
>> >>> Unless/unti
On Monday 09 January 2012 16:25:41 Tom Rini wrote:
> On Mon, Jan 9, 2012 at 2:23 PM, Tom Rini wrote:
> > On Mon, Jan 9, 2012 at 2:21 PM, Mike Frysinger wrote:
> >> On Monday 09 January 2012 14:41:07 Scott Wood wrote:
> >>> Unless/until the toolchain can properly GC anonymous strings, I think
> >>
On Monday 09 January 2012 16:27:44 Scott Wood wrote:
> On 01/09/2012 03:21 PM, Mike Frysinger wrote:
> > On Monday 09 January 2012 14:41:07 Scott Wood wrote:
> >> Unless/until the toolchain can properly GC anonymous strings, I think
> >> finer-grained conditional compilation is the way to go.
> >
On 01/09/2012 03:21 PM, Mike Frysinger wrote:
> On Monday 09 January 2012 14:41:07 Scott Wood wrote:
>> Unless/until the toolchain can properly GC anonymous strings, I think
>> finer-grained conditional compilation is the way to go.
>
> i think we should use GC when it works (we've found 1 case so
On Mon, Jan 9, 2012 at 2:23 PM, Tom Rini wrote:
> On Mon, Jan 9, 2012 at 2:21 PM, Mike Frysinger wrote:
>> On Monday 09 January 2012 14:41:07 Scott Wood wrote:
>>> Unless/until the toolchain can properly GC anonymous strings, I think
>>> finer-grained conditional compilation is the way to go.
>>
On Mon, Jan 9, 2012 at 2:21 PM, Mike Frysinger wrote:
> On Monday 09 January 2012 14:41:07 Scott Wood wrote:
>> Unless/until the toolchain can properly GC anonymous strings, I think
>> finer-grained conditional compilation is the way to go.
>
> i think we should use GC when it works (we've found 1
On Monday 09 January 2012 14:41:07 Scott Wood wrote:
> Unless/until the toolchain can properly GC anonymous strings, I think
> finer-grained conditional compilation is the way to go.
i think we should use GC when it works (we've found 1 case so far where it
doesn't), and add fine grained compilat
On 01/08/2012 03:56 AM, Mike Frysinger wrote:
> On Wednesday 04 January 2012 18:56:23 Scott Wood wrote:
>> On 12/05/2011 05:17 PM, Marek Vasut wrote:
>>> This will be beneficial for the PXA3XX NAND driver, which uses the NAND
>>> IDs to identify the chip and configure the controller accordingly.
>>
On Wednesday 04 January 2012 18:56:23 Scott Wood wrote:
> On 12/05/2011 05:17 PM, Marek Vasut wrote:
> > This will be beneficial for the PXA3XX NAND driver, which uses the NAND
> > IDs to identify the chip and configure the controller accordingly.
> >
> > --- a/drivers/mtd/nand/Makefile
> > +++ b/
On 01/06/2012 01:14 PM, Tom Rini wrote:
> On Fri, Jan 6, 2012 at 12:03 PM, Scott Wood wrote:
>> On 01/05/2012 06:41 PM, Tom Rini wrote:
>>> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood wrote:
Whatever the set of things is that you want to pull in for these SPLs,
it needs to be a separate
On Fri, Jan 6, 2012 at 12:03 PM, Scott Wood wrote:
> On 01/05/2012 06:41 PM, Tom Rini wrote:
>> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood wrote:
>>> Whatever the set of things is that you want to pull in for these SPLs,
>>> it needs to be a separate config option from the one that enables
>>> li
On 01/05/2012 06:41 PM, Tom Rini wrote:
> On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood wrote:
>> Whatever the set of things is that you want to pull in for these SPLs,
>> it needs to be a separate config option from the one that enables
>> libnand.o to be included, so that other SPLs can pull in sma
On Thu, Jan 5, 2012 at 4:04 PM, Scott Wood wrote:
> On 01/05/2012 08:15 AM, Tom Rini wrote:
>> On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut wrote:
I'll confirm gc-sections/etc are not as awesome as we think. You can
drop the size of current SPL builds (for say devkit8000) by taking
On 01/05/2012 08:15 AM, Tom Rini wrote:
> On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut wrote:
>>> I'll confirm gc-sections/etc are not as awesome as we think. You can
>>> drop the size of current SPL builds (for say devkit8000) by taking
>>> things that should be dropped for us and forcing them ou
On Thu, Jan 5, 2012 at 2:09 AM, Marek Vasut wrote:
>> On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood wrote:
>> > On 12/05/2011 05:17 PM, Marek Vasut wrote:
>> >> This will be beneficial for the PXA3XX NAND driver, which uses the NAND
>> >> IDs to identify the chip and configure the controller accordi
> On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood wrote:
> > On 12/05/2011 05:17 PM, Marek Vasut wrote:
> >> This will be beneficial for the PXA3XX NAND driver, which uses the NAND
> >> IDs to identify the chip and configure the controller accordingly.
> >>
> >> Signed-off-by: Marek Vasut
> >> Cc: Sc
On Wed, Jan 4, 2012 at 4:56 PM, Scott Wood wrote:
> On 12/05/2011 05:17 PM, Marek Vasut wrote:
>> This will be beneficial for the PXA3XX NAND driver, which uses the NAND IDs
>> to
>> identify the chip and configure the controller accordingly.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Scott Wood
>
On 12/05/2011 05:17 PM, Marek Vasut wrote:
> This will be beneficial for the PXA3XX NAND driver, which uses the NAND IDs to
> identify the chip and configure the controller accordingly.
>
> Signed-off-by: Marek Vasut
> Cc: Scott Wood
> ---
> drivers/mtd/nand/Makefile |4 ++--
> 1 files chan
This will be beneficial for the PXA3XX NAND driver, which uses the NAND IDs to
identify the chip and configure the controller accordingly.
Signed-off-by: Marek Vasut
Cc: Scott Wood
---
drivers/mtd/nand/Makefile |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
19 matches
Mail list logo
