<div dir="ltr">just noticed ive put it in cpu_bus_ops... have a laugh... <br>but i dont have "static struct device_operations mc_ops" - where should i add<br>the .ops_pci ?<br><br>Elia.<br><br><div class="gmail_quote">
On Tue, Nov 18, 2008 at 12:46 AM, Elia Yehuda <span dir="ltr"><<a href="mailto:z4ziggy@gmail.com">z4ziggy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">regarding the vendor/device id - ive added the following :<div class="Ih2E3d"><br><br>static void intel_set_subsystem(device_t dev, unsigned vendor, unsigned device)<br>{<br>    u32 pci_id;<br><br>    printk_debug("Setting PCI bridge subsystem ID\n");<br>

    pci_id = pci_read_config32(dev, 0);<br>    pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID, pci_id );<br>}<br><br>static struct pci_operations intel_pci_ops = {<br>       .set_subsystem    = intel_set_subsystem,<br>};<br>

<br></div>static struct device_operations cpu_bus_ops = {<br>    .read_resources        = cpu_bus_noop,<br>    .set_resources        = cpu_bus_noop,<br>    .enable_resources    = cpu_bus_noop,<br>    .init            = cpu_bus_init,<br>

    .scan_bus        = 0,<div class="Ih2E3d"><br>    .ops_pci        = &intel_pci_ops,<br>};<br><br></div>but it doesnt seems to do the trick. i don't even get "Setting PCI bridge subsystem ID" - am <br>
I missing something?<br><font color="#888888"><br>
Elia.<br><br></font><div class="gmail_quote"><div class="Ih2E3d">On Mon, Nov 17, 2008 at 3:58 PM, Stefan Reinauer <span dir="ltr"><<a href="mailto:stepan@coresystems.de" target="_blank">stepan@coresystems.de</a>></span> wrote:<br>
</div><div><div></div><div class="Wj3C7c"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>Elia Yehuda wrote:<br>
> Those 2 patches are one step towards having a working Onboard-VGA<br>
> and 512MB (the max for i810). The raminit.c patch fixes some<br>
> misconfigurations and probes the DIMMs correctly (all dual-sided are<br>
> now recognized properly), and also set buffer_strength to handle 2<br>
> DIMMs although atm this doesn't work. The i82810/northbridge.c patch<br>
> takes care of allocating Onboard-VGA memory.<br>
><br>
</div></div>> Signed-off-by: Elia Yehuda <<a href="mailto:z4ziggy@gmail.com" target="_blank">z4ziggy@gmail.com</a> <mailto:<a href="mailto:z4ziggy@gmail.com" target="_blank">z4ziggy@gmail.com</a>>><br>
<br>
Good work!<br>
<br>
But no ack yet, because it's ongoing work that also breaks some<br>
(potentially) working cases. I have a couple of comments though<br>
<br>
> +     for (i = 0; i < DIMM_SOCKETS ; i++) {<br>
> +             dimm_size = smbus_read_byte(ctrl->channel0[i], 31);<br>
> +             dimm_banks = smbus_read_byte(ctrl->channel0[i], 5);<br>
> +             if (dimm_size) {<br>
Can this be changed to read the size and banks values from the PCI<br>
registers or variables instead of from the smbus?<br>
It's a lot of slow, unneeded bus traffic for every ram read. I don't<br>
know about the 810, but other Intel chipsets would get confused by that<br>
kind of bus traffic and delays at that point.<br>
<br>
> +                      * Rows of Slot 1 are numbed 2 through 3. The<br>
> +                      * DIMM’s SPD Byte 5 describes the number of sides in a<br>
> +                      * DIMM; SPD Byte 13 provides information on<br>
Some weird character sneaked into that comment.<br>
<br>
> );<br>
> +     uint8_t val;<br>
> +     val = pci_read_config8(ctrl->d0, DRAMT);<br>
I suggest using PCI_DEV(0,0,0) instead of the indirection ctrl->d0 all<br>
over raminit.c.<br>
<br>
That indirection was invented for AMD K8 where in an SMP environment<br>
there are several memory controllers with several DIMMs attached to<br>
each. But the i810 definitely only supports a single memory controller,<br>
and the code can be kept a lot simpler.<br>
<br>
> +                     if ((smbus_read_byte(ctrl->channel0[i], 127) | 0xf) == 0xff) {<br>
Same here: Intel boards expect the SPD ROMs at fixed places, unlike the<br>
common case on Opteron boards.<br>
<br>
Also, your code only treats single channel configurations. Is the i810<br>
capable of dual channel operation?<br>
<br>
> -     /* TODO: This needs to be set according to the DRAM tech<br>
> +     /* TODO: This needs to be calculated according to the DRAM tech<br>
><br>
Don't think this can really be calculated. Looking at your findings<br>
below, you should probably use a table for this and look up the correct<br>
values from the table.<br>
>        * (x8, x16, or x32). Argh, Intel provides no docs on this!<br>
>        * Currently, it needs to be pulled from the output of<br>
>        * lspci -xxx Rx92<br>
> +      * here are some common results:<br>
> +      * value:   tom:    config:<br>
> +      * 0x3356   256MB   1 x 256MB DIMM(s), dual sided<br>
> +      * 0x0001   512MB   2 x 256MB DIMM(s), dual sided<br>
> +      * 0x77da   128MB   1 x 128MB DIMM(s), single sided<br>
> +      * 0x55c6   128MB   2 x 128MB DIMM(s), single sided<br>
> +      * 0x3356   128MB   1 x 128MB DIMM(s), dual sided<br>
> +      * 0x0001   256MB   2 x 128MB DIMM(s), dual sided<br>
>        */<br>
Because:<br>
> -     pci_write_config16(ctrl->d0, BUFF_SC, 0x77da);<br>
> +     /* use 2 dual sided DIMMs - this also works with only 1 DIMM */<br>
> +     pci_write_config16(ctrl->d0, BUFF_SC, 0x0001);<br>
> +<br>
This fixes one case and breaks another one. Not really an improvement.<br>
<br>
> +     /* set the GMCH to prechange all during the service of a page miss */<br>
><br>
precha_r_ge?<br>
<br>
> +     /* or we can use sane defaults, but VGA won't work for unknown reason */<br>
> +     //pci_write_config8(ctrl->d0, PAM, 0x41);<br>
This will prevent writes to the CSEG, will it? (Didn't check)<br>
<br>
> +     /* setting Vendor/Device ids - there must be a better way of doing<br>
> +      * this...<br>
> +      */<br>
> +     /* set vendor id */<br>
> +     val = pci_read_config16(ctrl->d0, 0);<br>
> +     pci_write_config16(ctrl->d0, 0x2c, val);<br>
> +     /* set device id */<br>
> +     val = pci_read_config16(ctrl->d0, 2);<br>
> +     pci_write_config16(ctrl->d0, 0x2e, val);<br>
Yes, during pci_set_subsystem_ids in northbridge.c:<br>
<br>
static void intel_set_subsystem(device_t dev, unsigned vendor, unsigned<br>
device)<br>
{<br>
        u32 pci_id;<br>
<br>
        printk_debug("Setting PCI bridge subsystem ID\n");<br>
        pci_id = pci_read_config32(dev, 0);<br>
        pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID, pci_id );<br>
}<br>
<br>
static struct pci_operations intel_pci_ops = {<br>
        .set_subsystem    = intel_set_subsystem,<br>
};<br>
<br>
static struct device_operations mc_ops = {<br>
        [..]<br>
        .ops_pci          = &intel_pci_ops,<br>
};<br>
<br>
>       /* 3. Perform 8 refresh cycles. Wait tRC each time. */<br>
>       PRINT_DEBUG("RAM Enable 3: CBR\r\n");<br>
> -     do_ram_command(ctrl, RAM_COMMAND_CBR, 0, row_offset);<br>
>       for (i = 0; i < 8; i++) {<br>
> +             do_ram_command(ctrl, RAM_COMMAND_CBR, 0, row_offset);<br>
> +             /* FIXME: are those read32() needed? */<br>
>               read32(0);<br>
>               read32(row_offset);<br>
>               udelay(1);<br>
Probably not needed the way you're doing it now. The reads cause a<br>
refresh cycle on a given dram rank. do_ram_command does one such read.<br>
Since several are needed they were done in a loop.<br>
<br>
Since do_ram_command does more stuff than just those reads, you might<br>
cause the controllers state machine to choke.<br>
<br>
Basically, doing any reads in do_ram_command() is a bad idea. They<br>
should instead be done when/where they need to happen. I suggest looking<br>
at the i945 code for an example.<br>
<br>
<br>
<br>
Stefan<br>
<font color="#888888"><br>
<br>
--<br>
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.<br>
      Tel.: +49 761 7668825 • Fax: +49 761 7664613<br>
Email: <a href="mailto:info@coresystems.de" target="_blank">info@coresystems.de</a>  • <a href="http://www.coresystems.de/" target="_blank">http://www.coresystems.de/</a><br>
Registergericht: Amtsgericht Freiburg • HRB 7656<br>
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866<br>
<br>
</font></blockquote></div></div></div><br></div>
</blockquote></div><br></div>