linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: zajec5@gmail.com (Rafał Miłecki)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC][PATCH] axi: add AXI bus driver
Date: Wed, 13 Apr 2011 23:58:12 +0200	[thread overview]
Message-ID: <BANLkTinXnZzF_1XkdDpuHsL-NWDd03VREw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTi=8HEysFXhcv5yn=ErWZkzzqPoSug@mail.gmail.com>

2011/4/13 Rafa? Mi?ecki <zajec5@gmail.com>:
> Will comment on that later.

Can we try to decide, how to implement our driver correctly? This
should be main focus for now. I tried to analyze drivers/amba/, how it
works, how it relates to our code, Broadcom.

AFAICS AMBA so far is mostly (always?) used for embedded devices with
pre-defined hardware layout. Let's take as example mach-u300 (just
some random one). One of the amba_devices it registers is uart0_device
which has two interesting fields:
.start = U300_UART0_BASE,
.end   = U300_UART0_BASE + SZ_4K - 1,
U300_UART0_BASE == (U300_SLOW_PER_PHYS_BASE+0x3000) == 0xc0013000
So this mach-u300 is well-specified device, every mach-u300 has uart0
at 0xc0013000.

It looks every AMBA device (like uart0) has some common fields, like:
u32 peripherialid0, peripherialid1, peripherialid2, peripherialid3;
u32 componentid0, componentid1, componentid2, componentid3;

I believe Broadcom's *agent* AKA *wrapper* is comparable to standard
amba device.

Of course agents/wrappers are not the same for every Broadcom AMBA AXI
card, so we can not use strict .start and .end declarations and the
same agents/wrappers for every card. Instead, we have to do scanning
of EPROM to read info about agents/wrappers.

If someone does not know: every core on Broadcom AMBA AXI card has
it's agent/wrapper. We access agent/wrapper registers to
enable/disable/reset core.

So we could scan EPROM for agents/wrappers, register them in AMBA
driver using our *_core_enable as AMBA's clock management.


Please verify if my understanding is correct. I tried to explain
easily whole situation I just analyzed.

If I'm right: is this really the right path to follow? What about real
core, like PCIe core, or IEEE core? I guess they are not standard AMBA
cores, so we can not simply register them. Should we look for clever
way to connect everything we have with drivers/amba? How to connect
"real" cores (PCIe, IEEE) with agents?

Please, share how do you see this situation now.

-- 
Rafa?

  reply	other threads:[~2011-04-13 21:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-11 23:57 [RFC][PATCH] axi: add AXI bus driver Rafał Miłecki
2011-04-11 23:22 ` Rafał Miłecki
2011-04-11 23:35 ` Greg KH
2011-04-12 13:04 ` Rafał Miłecki
2011-04-12 13:18   ` Arend van Spriel
2011-04-12 13:21     ` Rafał Miłecki
2011-04-12 13:27       ` Arend van Spriel
2011-04-12 13:36 ` Felipe Balbi
2011-04-12 18:47   ` George Kashperko
2011-04-12 18:59     ` Rafał Miłecki
2011-04-12 19:12       ` George Kashperko
2011-04-12 19:27         ` Rafał Miłecki
2011-04-12 19:34           ` George Kashperko
2011-04-12 19:46             ` Rafał Miłecki
2011-04-12 20:07               ` George Kashperko
2011-04-12 19:47           ` Hauke Mehrtens
2011-04-12 19:58             ` Rafał Miłecki
2011-04-12 20:13               ` Rafał Miłecki
2011-04-12 20:35                 ` George Kashperko
2011-04-12 20:44                   ` Rafał Miłecki
2011-04-12 20:57                     ` George Kashperko
2011-04-12 21:51                       ` SDHCI pre-rootfs kernel oops problem...? Nick Pelling
2011-04-13  8:16                     ` [RFC][PATCH] axi: add AXI bus driver Arend van Spriel
2011-04-13 19:50                       ` Rafał Miłecki
2011-04-13 20:23                         ` George Kashperko
2011-04-13 21:05                           ` Rafał Miłecki
2011-04-13 21:58                             ` Rafał Miłecki [this message]
2011-04-13 23:07                               ` Rafał Miłecki
2011-04-13 23:31                           ` Rafał Miłecki
2011-04-13 20:49                         ` Nick Bowler
2011-04-12 20:23             ` George Kashperko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTinXnZzF_1XkdDpuHsL-NWDd03VREw@mail.gmail.com \
    --to=zajec5@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).