On (Wed) Mar 24 2010 [21:04:08], Amit Shah wrote:
> Hello,
>
> When multiple hvc console ports are initialised and used via the
> virtio_console driver, I can interact with only the first console, the
> 2nd one doesn't respond.
>
> If I call hvc_kick() even if hvc_poll() returns 0, the 2nd consol
Ben
Attached is the previous failing one.
Thanks
Gino
2010/3/26 Benjamin Herrenschmidt
> On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote:
> > After trying the new code with "isync" and unsigned long long
> > convertion, this problem doesn't happen(I tested for several minutes).
> > B
I enabled the printing of all values. There is bigger gap between two
reading, it seems isync bring to performance drop.
Could you elaborate what does "closer that 64 tick together" mean?
You can see the attached log, the 0x40 is not always set.
Thanks
Gino
2010/3/26 Segher Boessenkool
> > Aft
On (Fri) Mar 26 2010 [10:30:31], Anton Blanchard wrote:
>
> Hi,
>
> > And this suggests that hvc_kick() is called before hvc_task is
> > initialised, ie, before hvc_init() is called.
> >
> > Does this help?
>
> Looks good, tests OK on my POWER5 box. Thanks!
>
> Tested-by: Anton Blanchard
Tha
On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote:
> After trying the new code with "isync" and unsigned long long
> convertion, this problem doesn't happen(I tested for several minutes).
> But the previous block of codes(lacking of isync) is borrowed from
> kernel. And if this is a bug of kernel
We are building a PCI-E device for use in an embedded system with an
85xx processor. One of our customers is adamant that linux PCI-E
hot-swap support will not allow us to either bring the device up after
linux boot (i.e., the PCI-E device must be present when linux scans for
PCI-E devices at
On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>>> It seems to me that there are plausible use cases for both direct-inclusion
>>> and indirection. I don't see any real problems with either, so I would vote
>>> f
> After trying the new code with "isync" and unsigned long long convertion,
> this problem doesn't happen(I tested for several minutes).
Do you now ever get two consecutive time readings that are closer
that 64 tick together? If not, it's simply hiding the problem.
Do you ever now read a value t
After trying the new code with "isync" and unsigned long long convertion,
this problem doesn't happen(I tested for several minutes). But the previous
block of codes(lacking of isync) is borrowed from kernel. And if this is a
bug of kernel?
Thanks
Gino
2010/3/26 Benjamin Herrenschmidt
> On Thu,
On Thu, Mar 25, 2010 at 6:53 PM, M. Warner Losh wrote:
> Most !linux systems are not GPL'd. They are BSDL, primarily, or some
> private license between seller and buyer. In any event, other OSes
> likely won't have the GPL issue.
You're probably right.
> But I'm confused. If you can't distri
In message:
Timur Tabi writes:
: The initrd thing is a good idea, but it doesn't help non-Linux
: operating systems. Then again, those OS's might not have any GPL
: issues, so it could be a moot point.
Most !linux systems are not GPL'd. They are BSDL, primarily, or some
private lic
On Mar 25, 2010, at 10:00 AM, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the right log.
>
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.
>
>
> Thanks
>
Hi,
> And this suggests that hvc_kick() is called before hvc_task is
> initialised, ie, before hvc_init() is called.
>
> Does this help?
Looks good, tests OK on my POWER5 box. Thanks!
Tested-by: Anton Blanchard
> diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
> index ba
On Thu, Mar 25, 2010 at 10:59:01AM -0600, Grant Likely wrote:
> On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> > Grant Likely wrote:
> >> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
> >>> It seems to me that there are plausible use cases for both
> >>> direct-inclusion
> >>> and
On Thu, 2010-03-25 at 16:00 -0600, Chris Friesen wrote:
> Shouldn't "upper" be cast to 64-bit before shifting?
Yup but that doesn't explain his results. I think Segher nailed it to a
stuck bit tho, so I would blame defective HW or HW used outside of
normal operating conditions (maybe the TB is sou
Grant Likely wrote:
On Thu, Mar 25, 2010 at 1:53 PM, Scott Wood wrote:
Grant Likely wrote:
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
Oh, I don't like that idea at all. Th
Grant Likely wrote:
> No, this isn't off in the weeds. I concede the point of needing to
> store firmware in a separate node, but I still don't agree with the
> argument that it needs to be anything more than an anonymous named
> blob.
I still don't understand what's so *bad* about having some k
On 03/25/2010 09:00 AM, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the right log.
>
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.
volatile unsigned long
On Thu, Mar 25, 2010 at 2:04 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> I don't know that it's strictly necessary in this case -- it looks like
>> there is a magic number in the firmware blob -- but I don't understand
>> the objection as a matter of principle. These device tree discussions
>
On Thu, Mar 25, 2010 at 1:53 PM, Scott Wood wrote:
> Grant Likely wrote:
>>
>> On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
>>>
>>> Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
>>>
>>> Oh, I don't like that idea
> In my program, the value of the 64-bit time base register is read
> out, and you will find the later value is even smaller than the earlier
> value from the log log_timebase.
> Do you have any idea about this problem, thanks for your any
> advice. Attached is the code and log
On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the
> right log.
>
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as
> 32-bit.
And despi
Scott Wood wrote:
> I don't know that it's strictly necessary in this case -- it looks like
> there is a magic number in the firmware blob -- but I don't understand
> the objection as a matter of principle. These device tree discussions
> have a tendency to get awfully bikesheddy.
I don't wa
Grant Likely wrote:
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
Oh, I don't like that idea at all. The compatible property is useful for me to
know *how* to parse the binary
Grant Likely wrote:
> Compatible is for devices. This is not a device. Drivers cannot bind
> against it. Use a different mechanism if you have metadata about the
> blob. If your driver doesn't know how to validate its own firmware
> blobs, then you've got bigger problems.
Perhaps. I left the
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> For indirect firmware, create a /chosen/firmware node. Don't add a
>> compatible property,
>
> Oh, I don't like that idea at all. The compatible property is useful for me
> to know *how* to parse the binary blob.
Comp
Grant Likely wrote:
> For indirect firmware, create a /chosen/firmware node. Don't add a
> compatible property,
Oh, I don't like that idea at all. The compatible property is useful for me to
know *how* to parse the binary blob.
> compatible is for devices and this node is for
> blob data.
On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>>> It seems to me that there are plausible use cases for both direct-inclusion
>>> and indirection. I don't see any real problems with either, so I would vote
>>> f
Timur Tabi wrote:
Grant Likely wrote:
On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
It seems to me that there are plausible use cases for both direct-inclusion
and indirection. I don't see any real problems with either, so I would vote
for specifying both alternatives.
Ugh. Then thi
Scott Wood wrote:
> It would be nice to not have to provide separate copies of the firmware
> to u-boot and Linux -- not from a space perspective, but support.
My plan was to take the copy that U-Boot already knows about (via macros like
CONFIG_SYS_QE_FW_ADDR) and have U-Boot dynamically embed
Grant Likely wrote:
> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>> It seems to me that there are plausible use cases for both direct-inclusion
>> and indirection. I don't see any real problems with either, so I would vote
>> for specifying both alternatives.
>
> Ugh. Then this one d
Grant Likely wrote:
[cc'd David Gibson]
On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi wrote:
The initrd thing is a good idea, but it doesn't help non-Linux
operating systems. Then again, those OS's might not have any GPL
issues, so it could be a moot point.
The more I think about it, the more
On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
> It seems to me that there are plausible use cases for both direct-inclusion
> and indirection. I don't see any real problems with either, so I would vote
> for specifying both alternatives.
Ugh. Then this one driver would need to implement
I am really sorry that the previously attached code is wrong, this one
"timebase.c" is the right one, and the "log_timebase" file is the right log.
We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.
Thanks
Gino
2010/3/25 Arnd Bergmann
> On Thursday 25 March 2010, Benja
Just a minor comment
On Tue, 2010-03-09 at 13:01 -0700, Jason Gunthorpe wrote:
> @@ -703,7 +747,17 @@ static int __init init_tis(void)
> return rc;
> }
>
> - return pnp_register_driver(&tis_pnp_driver);
> +#ifdef CONFIG_OF
> + rc = of_register_platform_driver(&tis_of_
[cc'd David Gibson]
On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi wrote:
> On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
> wrote:
>
>> I do; I consider that indirection thing (and putting firmware blobs
>> in the device tree at all, but to a lesser extent) as making a mess
>> of your device
It seems to me that there are plausible use cases for both
direct-inclusion and indirection. I don't see any real problems with
either, so I would vote for specifying both alternatives.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
http
Segher Boessenkool wrote:
As far as I can see, you want that indirection node so that you
safe space in the DTB.
Probably more of a general desire to not duplicate things that don't
need to be duplicated... I don't think the space issue is critical in
this particular case.
With real OF it
On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
wrote:
> I do; I consider that indirection thing (and putting firmware blobs
> in the device tree at all, but to a lesser extent) as making a mess
> of your device binding.
I guess we'll just have to agree to disagree.
> Let's forget that I do
On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
> On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> > In my program, the value of the 64-bit time base register is
> > read out, and you will find the later value is even smaller than the
> > earlier value from the log “log_time
On Wed, 2010-03-24 at 11:32 +0100, Romain Goyet wrote:
>
> Here's a summary about "how to boot a PowerMac G5 without a screen
> attached". As many people have noticed, default yaboot install won't
> boot unless a screen is attached.
>
> Actually, the workaround is really simple. Thing is, th
On Wed, Mar 24, 2010 at 1:26 PM, Benjamin Herrenschmidt
wrote:
> Some powerpc code needs to ensure that all previous iounmap/vunmap has
> really been flushed out of the MMU hash table. Without that, various
> hotplug operations may fail when trying to return those pieces to
> the hypervisor due to
> You want vm_unmap_aliases(), which also flushes entries in the
> per-cpu vmap allocator (and is already exported for other code
> that has similar problems).
Ok, I missed that one. I'll update my patch. Thanks.
Cheers,
Ben.
___
Linuxppc-dev mailing
On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> In my program, the value of the 64-bit time base register is
> read out, and you will find the later value is even smaller than the
> earlier value from the log “log_timebase”. While the kernel depends on
> the accuracy of the timebase
44 matches
Mail list logo
