From: Scott Wood [mailto:scottw...@freescale.com]
>> Hmm I guess there is no simple solution then, since the "recover"
>> function also prints the kernel messages about the machine check
>> being in kernel mode without having checked whether it really was in
>> kernel mode. In the past the user mod
From: Scott Wood [mailto:scottw...@freescale.com]
> > Therefore I request to put this check back, and even to put the
> > removed code at the top of the machine check handler because there is
> > no point in trying to recover from a user space bus error anyway.
>
> Why is there no point trying to
Alexandre Bounine wrote:
> After the host has completed enumeration of the entire network it releases
> devices by clearing device ID locks (calls rio_clear_locks()). For each
> endpoint
> -in the system, it sets the Master Enable bit in the Port General Control CSR
> +in the system, it sets the
David Laight wrote:
The in_le32() not only contains the unwanted 'sync', but also
a 'twi' (trap immediate - NFI exactly what this does) and 'isync'.
The 'isync' is particularly horrid and unnecessary (aborts
the instruction queue and refeches the opcode bytes).
I've also wondered why some time
Bounine, Alexandre wrote:
In the current fsl_rio implementation initialization enables ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I think
Btw, best is to use 0xFF (or 0x in 16-bit environment
Bounine, Alexandre wrote:
In the current fsl_rio implementation initialization enables ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I think
you are close to find a source of the problem.
Be aware t
Thomas Taranowski wrote:
use my trusty jtag to issue a Port Link Maintenance Request and
request status, I get back unrecoverable ackID error for port 1, and
error-stopped port_status for port 2.
Did you try rebooting all devices together?
Micha
___
Bounine, Alexandre wrote:
Micha Nelissen wrote:
I look at it this way: it prevents the need for another layer of
indirection: translating component tag to a destid.
The destid alone is not enough. You will need an entire rio_dev object
for that device anyway.
?? I did not say a rio_dev
Bounine, Alexandre wrote:
Micha Nelissen wrote:
that switch. The tag uses one extra bit to identify the device as a
switch instead of an endpoint. This provides the information to
unambiguously identify a switch from an endpoint.
OK taking away #2. But do not see how it justifies storing two
Bounine, Alexandre wrote:
Micha Nelissen wrote:
rid of rswitch->switchid and use component_tag directly for
switches).
I still prefer the destid as the single identification id.
In your patch you allocate individual destid for switches. This method
has two problems:
1. The destid for
Bounine, Alexandre wrote:
Micha Nelissen wrote:
rswitch->rdev->destid should be the id associated with a given switch,
so that every (processor) device can agree what id some switch has.
If we will need to identify the same physical switch by different
processors we may use the compone
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
How can you say this? The two variables have different meanings, this
logically implies you can't merge them. So how do you say 'this does
not
prevent us from ...' without providing a reason?
Looks li
Alexandre Bounine wrote:
1. Using one storage location common for switches and endpoints eliminates
unnecessary device type checks during maintenance access operations.
While destination IDs and hop counts have different meaning for endpoints and
switches, this does not prevent us from storing th
Hi Bastian,
Bastiaan Nijkamp wrote:
It seems i forgot to include the relevant TLB entries in U-Boot and the
Device Tree in the e-mail, so here they are:
The TLB entries in U-Boot:
The kernel maintains the TLB, you must not set those in U-boot. It might
cause conflicts when the kernel choose
Carlos Roberto Moratelli wrote:
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
Yes, vendor and device id must match. You can find those in lspci.
Mic
Hi Alex,
Bounine, Alexandre wrote:
struct rio_dev {
struct list_head global_list;
struct list_head net_list;
.
. rest of rio_dev
.
struct rio_switch switch[0];
}
It makes sense to let rio_dev structures point to the switch they are
attached to. That can be
Bounine, Alexandre wrote:
Micha Nelissen wrote:
This is not 'Gen2' specific, as these error management extensions also
exist in v1.2/1.3 (?) of the specification? E.g. tsi56x and tsi57x
could
support this functionality?
Correct. EM extensions exist since v1.3. But implementation b
Bounine, Alexandre wrote:
That "real" PW message may be dropped by the controller (85xx is good
example). Everything depends on number of PW messages directed to the
host/controller. I am trying to use the first available notification to
service device removal. If the "real" PW message is receive
Bounine, Alexandre wrote:
Why not make a sw_sysfs_create and sw_sysfs_remove? Is better for
readability. Now you call 'sw_sysfs(dev, 0)' or 'sw_sysfs(dev, 1)';
I just do not want to have an extra member here. Not every switch will
require own sysfs attributes, but every switch will be presented
Bounine, Alexandre wrote:
capable to receive and keep only one PW message. Therefore, I copy it
into the driver's FIFO and re-enable HW Rx queue (it is called queue but
can accept only one entry) ASAP. I have a test setup that is capable
generate multiple PW messages and see many messages discard
Bounine, Alexandre wrote:
As RapidIO is a switched network, the concept of 'previous' and 'next'
devices is invalid. Perhaps it's just the way they were
discovered/enumerated, but that does not matter any more at runtime.
Or at least, should not matter.
Yes, the "previous" and "next" have to b
Alexandre Bounine wrote:
+ rio_mport_write_config_32(mport, destid, hopcount,
+ LOCAL_RTE_CONF_DESTID_SEL, table);
+
+ for (i = 0x8000; i <= 0x80ff;) {
+ rio_mport_write_config_32(mport, destid, hopcount,
+ RI
Alexandre Bounine wrote:
This set of RapidIO patches adds support for new IDT Gen2 sRIO switch
devices - CPS-1848 and CPS-1616.
Adding these sRIO switches required to implement standard error recovery
mechanism defined by the RapidIO specification.
This is not 'Gen2' specific, as these error ma
Alexandre Bounine wrote:
Add check if PW message source device is accessible and change PW message
handler to recover if PW message source device is not available anymore (power
down or link disconnect).
I am not quite sure what the point is of this patch. What do you need to
recover from?
Alexandre Bounine wrote:
- if (!rdev->rswitch)
- goto out;
-
Is it safe? All devices have a switch?
@@ -63,10 +59,11 @@ struct device_attribute rio_dev_attrs[] = {
__ATTR_RO(asm_did),
__ATTR_RO(asm_vid),
__ATTR_RO(asm_rev),
- __ATTR_RO(routes)
Alexandre Bounine wrote:
- Rearranged RIO port-write interrupt handling to perform message buffering
as soon as possible.
I don't understand this comment: you still schedule work to read the
port-write queue; so how is this message buffering performed as soon as
possible?
- Modified to dis
Alexandre Bounine wrote:
A switch ingress port number has to be saved for software assisted error
recovery from the error-stopped state. Saving this information also allows
to remove several register reads from the RIO enumeration process.
Why not keep using the swpinfo field, as you can extrac
Alexandre Bounine wrote:
+
+ if (err_status & RIO_PORT_N_ERR_STS_PW_OUT_ES) {
+ pr_debug("RIO_EM: servicing Output Error-Stopped state\n");
+ /*
+* Send a Link-Request/Input-Status control symbol
+*/
+
+ /* Read from
Alexandre Bounine wrote:
Create back and forward links between RIO devices. These links are intended for
use by error management and hot-plug extensions.
As RapidIO is a switched network, the concept of 'previous' and 'next'
devices is invalid. Perhaps it's just the way they were
discovered/e
Micha Nelissen wrote:
Do you mean like attached? I had to change the order of the '_GLOBAL'
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
e500v2 only.
Hmm, maybe need to use r0 or r3 instead of r2?
Micha
Index: linux/arch/powerpc/kernel/cpu_setup_f
Kumar Gala wrote:
+BEGIN_MMU_FTR_SECTION
+ mfspr r2,SPRN_HID0
+ ori r2,r2,hid0_en_mas7_upd...@l
+ mtspr SPRN_HID0, r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
+#endif
If you want to do this, do it in:
arch/powerpc/kernel/cpu_setup_fsl_booke.S
Do you mean like at
Timur Tabi wrote:
I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing.
Why?
That's
just the way it works.
What a great design philosophy!
Linux patches that repeat what U-Boot already
does just so that you do
Aggrwal Poonam-B10812 wrote:
Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence
possibly u-boot has to made aware of large physical address space.
Please correct me if I am wrong.
Yes, I can
Aggrwal Poonam-B10812 wrote:
Attached is a patch to fix large physical address support for the
This is already being done by u-boot, should linux set it again?
Yikes! Took me 5 min to reformat your email.
Our version of U-boot does not but it's not latest greatest.
IMHO:
1) Linux should not
Hi,
Attached is a patch to fix large physical address support for the e500v2
core. When >4GB addresses are used, the MAS7 register needs to be valid
for tlbsx instruction usage.
Please review and apply.
Micha
diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h
linux-2.6.34-fix/arch/powe
Kumar Gala wrote:
We shouldn't be always setting 'M' in the TLB entry since its reasonable
for somethings to be mapped non-coherent. The PTE should have 'M' set
properly.
properly = not at all? AFAICS the patch only removes the setting of the
bit; so where is that 'M' bit set then?
Micha
__
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the vid
+ * and did match a switch table
e register at offset > 4MB? The Tundra's have
registers going up to 0x14000 or so? So don't need 16MB addressing for that.
Thanks, Micha
-Original Message-----
From: Micha Nelissen [mailto:mi...@neli.hopto.org]
Sent: Wednesday, February 24, 2010 3:21 PM
To: Alexandre Bounine
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
+ mport->host_deviceid = RIO_GET_DID(mport->sys_size,
This fixes something else, should be a separate patch.
This sets an ID used for locking during discovery. On a startup only
enumerator's I
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a particular vendor
switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the vid
+ * and did match a switch table entry, then set the em_init() and
+ * em_handle() ops t
Alexandre Bounine wrote:
@@ -369,6 +380,10 @@ static struct rio_dev __devinit *rio_set
rdev->rswitch->switchid);
rio_route_set_ops(rdev);
+ if (do_enum && rdev->rswitch->clr_table)
+ rdev->rswitch->clr_table(port, destid, hopc
Alexandre Bounine wrote:
+ /* Attempt to acquire device lock */
+ rio_mport_write_config_32(port, destid,
+ hopcount,
+ RIO_H
Signed-off-by: Micha Nelissen
---
arch/powerpc/sysdev/fsl_rio.c | 175 -
drivers/rapidio/rio-scan.c|3 +-
drivers/rapidio/rio.c | 121 -
include/linux/rio.h | 20 -
include/linux/rio_drv.h
hank peng wrote:
I remember normal memory copy can also be done (chosen by user) by DMA
engine on IOP80331(Intel embedded cpu, xscale arch), so why ppc
platform didn't make use of DMA doing memory copy, I think it can
increase performance, please correct me if I am wrong!
AFAIK the DMA engine h
Michael Buesch wrote:
Yes, I think the barrier is wrong.
Please try with
#define mb()__asm__ __volatile__("eieio\n sync\n" : : : "memory")
For uncached memory, eieio should be enough.
Micha
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlab
ired behaviour that my application is killed with a
SIGBUS, and the rest of the kernel keeps running properly?
Thanks in advance for any insight,
Micha Nelissen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
46 matches
Mail list logo
