From: George Kashperko <george@znau.edu.ua>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Greg KH" <greg@kroah.com>,
linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>,
b43-dev@lists.infradead.org, "Michael Büsch" <mb@bu3sch.de>,
"Larry Finger" <Larry.Finger@lwfinger.net>,
"Arend van Spriel" <arend@broadcom.com>,
linux-arm-kernel@lists.infradead.org,
"Russell King" <rmk@arm.linux.org.uk>,
"Arnd Bergmann" <arnd@arndb.de>,
"Andy Botting" <andy@andybotting.com>,
linuxdriverproject <devel@linuxdriverproject.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH V4] axi: add AXI bus driver
Date: Wed, 13 Apr 2011 23:45:16 +0300 [thread overview]
Message-ID: <1302727516.8015.9.camel@dev.znau.edu.ua> (raw)
In-Reply-To: <BANLkTimwZOJ0a5kVfaUzEcsMc39H999u0A@mail.gmail.com>
> 2011/4/13 George Kashperko <george@znau.edu.ua>:
> >
> > В Срд, 13/04/2011 в 21:39 +0200, Rafał Miłecki пишет:
> >> 2011/4/13 Greg KH <greg@kroah.com>:
> >> >> diff --git a/drivers/axi/axi_pci_bridge.c b/drivers/axi/axi_pci_bridge.c
> >> >> new file mode 100644
> >> >> index 0000000..17e882c
> >> >> --- /dev/null
> >> >> +++ b/drivers/axi/axi_pci_bridge.c
> >> >> @@ -0,0 +1,33 @@
> >> >> +/*
> >> >> + * AXI PCI bridge module
> >> >> + *
> >> >> + * Licensed under the GNU/GPL. See COPYING for details.
> >> >> + */
> >> >> +
> >> >> +#include "axi_private.h"
> >> >> +
> >> >> +#include <linux/axi/axi.h>
> >> >> +#include <linux/pci.h>
> >> >> +
> >> >> +static DEFINE_PCI_DEVICE_TABLE(axi_pci_bridge_tbl) = {
> >> >> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4331) },
> >> >> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4353) },
> >> >> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4727) },
> >> >> + { 0, },
> >> >> +};
> >> >> +MODULE_DEVICE_TABLE(pci, axi_pci_bridge_tbl);
> >> >> +
> >> >> +static struct pci_driver axi_pci_bridge_driver = {
> >> >> + .name = "axi-pci-bridge",
> >> >> + .id_table = axi_pci_bridge_tbl,
> >> >> +};
> >> >> +
> >> >> +int __init axi_pci_bridge_init(void)
> >> >> +{
> >> >> + return axi_host_pci_register(&axi_pci_bridge_driver);
> >> >> +}
> >> >> +
> >> >> +void __exit axi_pci_bridge_exit(void)
> >> >> +{
> >> >> + axi_host_pci_unregister(&axi_pci_bridge_driver);
> >> >> +}
> >> >
> >> > You register a pci driver that does nothing? That's not right, you need
> >> > to then base your axi bus off of that pci device, so it is hooked up
> >> > correctly in the /sys/devices/ tree. Otherwise you are somewhere up in
> >> > the virtual location for your axi bus, right?
> >>
> >> Please take a look at:
> >> driver->probe = axi_host_pci_probe;
> >> driver->remove = axi_host_pci_remove;
> >> return pci_register_driver(driver);
> >>
> >>
> >> >> +bool axi_core_is_enabled(struct axi_device *core)
> >> >> +{
> >> >> + if ((axi_aread32(core, AXI_IOCTL) & (AXI_IOCTL_CLK | AXI_IOCTL_FGC))
> >> >> + != AXI_IOCTL_CLK)
> >> >> + return false;
> >> >> + if (axi_aread32(core, AXI_RESET_CTL) & AXI_RESET_CTL_RESET)
> >> >> + return false;
> >> >> + return true;
> >> >> +}
> >> >> +EXPORT_SYMBOL(axi_core_is_enabled);
> >> >
> >> > EXPORT_SYMBOL_GPL()?
> >> >
> >> > What module uses this? And why would it care?
> >> >
> >> >> +EXPORT_SYMBOL(axi_core_enable);
> >> >
> >> > EXPORT_SYMBOL_GPL()?
> >> >
> >> > Same goes for your other exports, just want you to be sure here.
> >>
> >> Hm, I'm not sure. Using EXPORT_SYMBOL_GPL will forbid closed source
> >> drivers from using our bus driver, right? I'm don't have preferences
> >> on this, if you prefer us to force GPL, I can.
> >>
> >>
> >> >> +u32 xaxi_chipco_gpio_control(struct axi_drv_cc *cc, u32 mask, u32 value)
> >> >> +{
> >> >> + return axi_cc_write32_masked(cc, AXI_CC_GPIOCTL, mask, value);
> >> >> +}
> >> >> +EXPORT_SYMBOL(xaxi_chipco_gpio_control);
> >> >
> >> > "xaxi"? Shouldn't that be consistant with the other exports and start
> >> > with "axi"?
> >>
> >> Left from old tests/rewrites/splitting. Thanks.
> >>
> >>
> >> >> +static u8 axi_host_pci_read8(struct axi_device *core, u16 offset)
> >> >> +{
> >> >> + if (unlikely(core->bus->mapped_core != core))
> >> >
> >> > Are you sure about the use of unlikely in this, and other functions?
> >> > The compiler almost always does a better job than we do for these types
> >> > of calls, just let it do it's job.
> >> >
> >> >> + axi_host_pci_switch_core(core);
> >> >> + return ioread8(core->bus->mmio + offset);
> >> >
> >> > I think because of that unlikely, you just slowed down all pci devices,
> >> > right? That's not very nice :)
> >>
> >> Hm, my logic suggests it is alright, but please consider this once
> >> more with me ;)
> >>
> >> For the most of the time mapped_core (active core) do not change. We
> >> perform few hundreds of operations on one core in a row. This way
> >> mapped_core points to passed core for most of the time. Condition
> >> (mapped_core != core) is unlikely to happen.
> >>
> >> Is there anything wrong in my logic?
> >>
> > Yes, there is. You don't need that "if" at all.
>
> Damn, WHY do you make me ask why, why, why, all the time?! Can't you
> just write word of explanation without being asked for?
>
Errm... Sorry, but I've already explained PCIE host behaviour _several_
times several days ago. Personally I like to ask questions. Have
absolutely nothing agains anyone else asking good questions. Never try
to make people ask me questions I know they would ask anyway. Really you
might missed some my messages earlier or maybe my english is too awful ?
Yet again, for PCIE cores (not only for them, for some PCI cores as
well) buscommon, buscore and function core are all available
simultaneously. You dont need window sliding when access them.
Have nice day,
George
next prev parent reply other threads:[~2011-04-13 20:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 18:52 [RFC][PATCH V4] axi: add AXI bus driver Rafał Miłecki
2011-04-13 16:31 ` Greg KH
2011-04-13 19:39 ` Rafał Miłecki
2011-04-13 20:31 ` George Kashperko
2011-04-13 20:40 ` Rafał Miłecki
2011-04-13 20:45 ` George Kashperko [this message]
2011-04-13 20:55 ` Rafał Miłecki
2011-04-13 21:14 ` George Kashperko
2011-04-13 21:19 ` Rafał Miłecki
2011-04-13 21:24 ` George Kashperko
2011-04-13 21:33 ` Rafał Miłecki
2011-04-13 23:36 ` Jonas Gorski
2011-04-14 9:51 ` Rafał Miłecki
2011-04-13 20:37 ` Gábor Stefanik
2011-04-13 21:00 ` Greg KH
2011-04-13 21:02 ` Greg KH
2011-04-13 18:24 ` Larry Finger
2011-04-13 19:40 ` Rafał Miłecki
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=1302727516.8015.9.camel@dev.znau.edu.ua \
--to=george@znau.edu.ua \
--cc=Larry.Finger@lwfinger.net \
--cc=andy@andybotting.com \
--cc=arend@broadcom.com \
--cc=arnd@arndb.de \
--cc=b43-dev@lists.infradead.org \
--cc=devel@linuxdriverproject.org \
--cc=greg@kroah.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=rmk@arm.linux.org.uk \
--cc=zajec5@gmail.com \
/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).