Thanks scott.
There was an issue with the file system. Now my board is up with the
linux boot prompt .
But ping is not working. The local loopback ping works. My phy chip
BCM5221 is connected on port A
I am using FCC1 as the MAC. I see that the intrrupt handler is being
registered properly. And
Hi David,
On Fri, 26 Aug 2011 14:49:02 +1000 David Gibson wrote:
>
> Jon, please apply. Uh.. except that this is a patch against the in
> kernel dtc, rather than upstream.
Yeah, Josh pointed out that these are fixed in upstream. I guess we need
to do another snapshot merge ...
--
Cheers,
Ste
On Fri, Aug 26, 2011 at 11:26:43AM +1000, Stephen Rothwell wrote:
> I assume that these variables were used in the past but not removed when
> their usage was removed.
>
> Fixes these warnings:
>
> scripts/dtc/dtc.c: In function 'main':
> scripts/dtc/dtc.c:102:17: warning: variable 'check' set bu
On Wed, Aug 24, 2011 at 09:41:43PM -0300, Thiago Jung Bauermann wrote:
> On Wed, 2011-08-24 at 14:00 +1000, David Gibson wrote:
> > On Tue, Aug 23, 2011 at 02:57:56PM +0530, K.Prasad wrote:
> > > On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote:
> > > > On Fri, Aug 19, 2011 at 01:23:38P
On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
>
> On 25.08.2011, at 07:31, Roedel, Joerg wrote:
>
> > On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> >> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> >
>
> [...]
>
> >> We need to try the polite m
On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
>
> > > I don't see a reason to make this meta-grouping static. It would harm
> > > flexibility on x86.
Hi all,
On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi wrote:
>
> The ePAPR hypervisor byte channel driver is supposed to work on all
> ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
> bit, which is available only on Book-E systems.
>
> Also fix a couple integer-to
I assume that these variables were used in the past but not removed when
their usage was removed.
Fixes these warnings:
scripts/dtc/dtc.c: In function 'main':
scripts/dtc/dtc.c:102:17: warning: variable 'check' set but not used
[-Wunused-but-set-variable]
scripts/dtc/flattree.c: In function 'fla
Hi Arnaud,
On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe wrote:
>
> If you could provide an exhaustive list of them, I'd be interested. Do
> you account/reference them in the report you make on each new -next
> tree ?
I don't refer to them at all :-(
If you are not just referring to powerpc
Hi,
On Thu, Aug 25, 2011 at 3:24 PM, Timur Tabi wrote:
> Arnaud Lacombe wrote:
>> This should fix the following warning:
>>
>> LD arch/powerpc/sysdev/xics/built-in.o
>> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch
>> in
>> reference from the function .icp_na
On 08/25/2011 02:57 AM, smitha.va...@wipro.com wrote:
> Hi Scott,
>
> I am currently trying to bring up 2.6.39 kernel on a target based on MPC8247
> Processor, using the attched .dts file . I get the below logs while the
> kernel is booting.
> I see that the unflattening of the device tree and th
Arnaud Lacombe wrote:
> This should fix the following warning:
>
> LD arch/powerpc/sysdev/xics/built-in.o
> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch
> in
> reference from the function .icp_native_init() to the function
> .init.text:.icp_native_init_one_no
On Thu, Aug 25, 2011 at 01:51:20PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > But don't you really want this type of check at runtime? What happens
> > if you load this driver on a machine that is not a guest? Will things
> > break? Shouldn't you still refuse to load somehow?
>
> This is in
Greg KH wrote:
> But don't you really want this type of check at runtime? What happens
> if you load this driver on a machine that is not a guest? Will things
> break? Shouldn't you still refuse to load somehow?
This is in the udbg code, which falls under the category of, "turn this on only
if
On Thu, Aug 25, 2011 at 01:02:01PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > tested doesn't mean that it shouldn't still build properly for other
> > platforms, right?
>
> The problem is the dependency on MSR_GS, which is defined only for Book-E
> PowerPC chips, not all PowerPC.
>
> So I gave
The ePAPR hypervisor byte channel driver is supposed to work on all
ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
bit, which is available only on Book-E systems.
Also fix a couple integer-to-pointer typecast problems.
Signed-off-by: Timur Tabi
---
drivers/tty/eh
On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iomm
Greg KH wrote:
> tested doesn't mean that it shouldn't still build properly for other
> platforms, right?
The problem is the dependency on MSR_GS, which is defined only for Book-E
PowerPC chips, not all PowerPC.
So I gave it some more thought, and technically ePAPR extends beyond Book-E, so
it's
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> Hi Alex,
>
> On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> > Is this roughly what you're thinking of for the iommu_group component?
> > Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> > support
On Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote:
> On 08/25/2011 06:54 AM, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iommu-ops per-bus.
>
On Thu, Aug 25, 2011 at 11:20:45AM -0500, Timur Tabi wrote:
> The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on
> PPC",
> which means it would compile on all PowerPC platforms, even though it's
> only been tested on Freescale platforms. Change the Kconfig to depend on
> F
The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on PPC",
which means it would compile on all PowerPC platforms, even though it's
only been tested on Freescale platforms. Change the Kconfig to depend on
FSL_SOC instead.
Signed-off-by: Timur Tabi
---
drivers/tty/Kconfig |
Hi,
On Thu, Aug 25, 2011 at 11:51 AM, Stephen Rothwell
wrote:
> Hi Timur,
>
> On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi wrote:
>>
>> Is there some trick to building allyesconfig on PowerPC? When I do try
>> that, I
>> get all sorts of weird build errors, and it dies long before it gets to
This should fix the following warning:
LD arch/powerpc/sysdev/xics/built-in.o
WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in
reference from the function .icp_native_init() to the function
.init.text:.icp_native_init_one_node()
The function .icp_native_init()
Greg KH wrote:
> No, this doesn't work, I need just a fix, as I took your previous patch
> already.
Sorry, coming right up.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
On Thu, Aug 25, 2011 at 10:32:25AM -0500, Timur Tabi wrote:
> The ePAPR embedded hypervisor specification provides an API for "byte
> channels", which are serial-like virtual devices for sending and receiving
> streams of bytes. This driver provides Linux kernel support for byte
> channels via thr
Hi Timur,
On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi wrote:
>
> Is there some trick to building allyesconfig on PowerPC? When I do try that,
> I
> get all sorts of weird build errors, and it dies long before it gets to my
> driver. I get stuff like:
>
> LD arch/powerpc/sysdev/xics/b
On 08/25/2011 06:54 AM, Roedel, Joerg wrote:
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This pr
Greg KH wrote:
>> > MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is
>> > included by arch/powerpc/include/asm/reg.h but only when defined
>> > (CONFIG_BOOKE) || defined(CONFIG_40x).
> Thanks for the report.
>
> Timur, care to send a fixup patch for this so this gets resolved?
I
On 25.08.2011, at 07:31, Roedel, Joerg wrote:
> On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
>> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
>
[...]
>> We need to try the polite method of attempting to hot unplug the device
>> from qemu first, which the current v
On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc':
> drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' un
On Aug 25, 2011, at 9:08 AM, Greg KH wrote:
> On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote:
>>
>
> Thanks for the report.
>
> Timur, care to send a fixup patch for this so this gets resolved?
Yes, I will do it ASAP, probably within the next two hours.
>
___
On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> > On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
> > > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> >
> > > > Handling it through fds is a goo
Clearing the other TCR bits might break code that sets them (e.g. to setup
the watchdog or fixed interval timer) before start_cpu_decrementer() gets
called.
Signed-off-by: Laurentiu Tudor
---
arch/powerpc/kernel/time.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arc
Hi:
When set MTU to 9600 by gfar_change_mtu(), the maxfrm register will
be set to 9728 which is greater than 9600 in gianfar.c.
But the MPC8315 Reference manual says the value of maxfrm can not
greater than 9600.
Is it a defect, Do we need to fix it?
--
Best Reagrds,
Roy | RongQing Li
___
Hi,
LiuShuo a écrit :
> 于 2011年08月23日 18:02, Matthieu CASTET 写道:
>> LiuShuo a écrit :
>>> 于 2011年08月19日 00:25, Scott Wood 写道:
On 08/17/2011 09:33 PM, b35...@freescale.com wrote:
> From: Liu Shuo
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to
On Tue, 2011-08-23 at 11:12 -0500, Scott Wood wrote:
> On 08/23/2011 05:02 AM, Matthieu CASTET wrote:
> > LiuShuo a écrit :
> >> We can't read the NOP from the ID on any chip. Some chips don't
> >> give this infomation.(e.g. Micron MT29F4G08BAC)
>
> Are there any 4K+ chips (especially ones with in
On 2011-08-25 01:57, smitha.va...@wipro.com wrote:
Hi Scott,
I am currently trying to bring up 2.6.39 kernel on a target based on MPC8247
Processor, using the attched .dts file . I get the below logs while the kernel
is booting.
I see that the unflattening of the device tree and the initial loa
On Mon, 2011-08-22 at 10:58 -0500, Scott Wood wrote:
> On 08/22/2011 05:58 AM, Artem Bityutskiy wrote:
> > On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> >> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> >>> How the bad block marker are handled with this remapping ?
> >>
> >> It has to be
On Wed, Aug 24, 2011 at 10:56:13AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
> > A side-note: Might it be better to expose assigned devices in a guest on
> > a seperate bus? This will make it easier to emulate an IOMMU for the
> > guest inside qemu.
>
>
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> Is this roughly what you're thinking of for the iommu_group component?
> Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> support in the iommu base. Would AMD-Vi do something similar (or
> exactly
On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan wrote:
> The mmc_delay() is a wrapper function for mdelay() and msleep().
>
> o mdelay() -- block the system when busy-waiting.
> o msleep() -- suspend the currently running task to enable CPU
> to process other tasks, so it is non
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
W
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
W
45 matches
Mail list logo
