* [PATCH 1/8] ARM: Add platform support for Fujitsu MB86S7X SoCs
From: Arnd Bergmann @ 2014-07-17 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJe_Zhc91g1=CTJUBaFaqk9Np4u4oEqddZEx_zeVxn7EdMEjmw@mail.gmail.com>
On Thursday 17 July 2014 19:02:53 Jassi Brar wrote:
> On 16 July 2014 01:39, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 15 July 2014 23:07:58 Jassi Brar wrote:
>
> >> >> diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
> >> >> new file mode 100644
> >> >> index 0000000..44f5b0c
> >> >> --- /dev/null
> >> >> +++ b/arch/arm/mach-mb86s7x/Kconfig
> >> >> @@ -0,0 +1,18 @@
> >> >> +config ARCH_MB86S7X
> >> >> + bool "Fujitsu MB86S7x platforms" if (ARCH_MULTI_V7 && ARM_LPAE)
> >> >> + select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
> >> >
> >> > Why the LPAE dependency? Is none of the RAM reachable by regular
> >> > kernels?
> >> >
> >> Some devices like PCI, LLI need it and the S70-evb has half of its ram
> >> above 4GB.
> >> Maybe ARM_LPAE should be selected by inclusion of support for those?
> >
> > No, you can't select ARM_LPAE because that would break machines that
> > do not support it in the same configuration.
> >
> To be clear, I meant selecting LPAE from config options specific to
> S70-evb and PCI on S7x.
I understood that.
> > Losing half the RAM or PCI should not be a problem, you'd just run
> > with reduced functionality. You wouldn't want to do that in practice,
> > but it's different from a hard dependency.
> >
> Sorry I am not sure what you mean. Is it ok as such?
What I mean is that it should be ok to drop the dependency, but you
can't add a 'select ARM_LPAE'. The memory should be handled correctly
already (you will just not see the upper 2GB), while the PCI host
driver should probably be checked for its error handling so it
prints a meaningful error message when it can't reach its MMIO space.
> >> >> +static void got_data(u32 code)
> >> >> +{
> >> >> + struct completion *c = NULL;
> >> >> + mhu_handler_t hndlr = NULL;
> >> >> + unsigned long flags;
> >> >> + int ev;
> >> >> +
> >> >> + if (code & RESP_BIT)
> >> >> + ev = EV_RR;
> >> >> + else
> >> >> + ev = EV_RC;
> >> >> +
> >> >> + spin_lock_irqsave(&fsm_lock, flags);
> >> >> +
> >> >> + if (mhu_fsm[fsm_state][ev] == MHU_INVLD) {
> >> >> + spin_unlock_irqrestore(&fsm_lock, flags);
> >> >> + pr_err("State-%d EV-%d FSM Broken!\n", fsm_state, ev);
> >> >> + return;
> >> >> + }
> >> >> + fsm_state = mhu_fsm[fsm_state][ev];
> >> >> +
> >> >> + if (code & RESP_BIT) {
> >> >> + c = ax->c;
> >> >> + memcpy_fromio(ax->buf, rsp_from_scb, ax->len);
> >> >> + list_move(&ax->node, &free_xfers);
> >> >> + ax = NULL;
> >> >> + } else {
> >> >> + /* Find and dispatch relevant registered handler */
> >> >> + if (code < MHU_NUM_CMDS)
> >> >> + hndlr = handler[code];
> >> >> + if (!hndlr)
> >> >> + pr_err("No handler for CMD_%u\n", code);
> >> >> + }
> >> >> +
> >> >> + spin_unlock_irqrestore(&fsm_lock, flags);
> >> >> +
> >> >> + if (hndlr)
> >> >> + hndlr(code, cmd_from_scb);
> >> >> + if (c)
> >> >> + complete(c);
> >> >> +}
> >> >> +
> >> >> +static void mhu_recv(struct mbox_client *cl, void *data)
> >> >> +{
> >> >> + got_data((u32)data);
> >> >> + schedule_work(&scb_work);
> >> >> +}
> >> >
> >> > Why the cast between integer and pointer?
> >> >
> >> The common mailbox framework passes around pointers to data packets.
> >> Its completely between controller and client drivers to decide the
> >> format of the packet. In my case the packet is a simple u32 value.
> >
> > I don't think the mailbox framework should allow that much
> > flexibility, because that would break portable drivers that
> > rely on a particular behavior from the mailbox provider.
> >
> > I understand that your driver is not portable to another mailbox
> > provider, but it still seems like a mistake in the API that should
> > better be fixed sooner than later.
> >
> Here is what I remember of many discussions on the point over the last year :)
> o We want to support zero-copy receives, which implies the mailbox
> framework must simply forward the pointer to "data packet" from
> controller to client driver.
> o We could not think of a generic enough structure for 'data packet'
> that could fit all protocols. So we assume the data packet format is
> an explicit understanding between the controller(+remote) and the
> client driver.
>
> Or did I miss your point?
Forwarding a pointer is ok, but then I think you should not overload
the 'void *data' argument. In the case above, you don't actually use
a pointer at all, but instead you use a 'code' that is taken as
an index into an array or a flag.
This is particularly broken when you think about 64-bit machines
on which you cannot cast a pointer to an u32.
What I think you should do is define your own data type for the
mailbox, which would be specific to your mailbox client and change
the code above to
struct mhu_mbox_message {
u32 code; /* another client could store a pointer here */
};
static void mhu_recv(struct mbox_client *cl, void *data)
{
struct mhu_mbox_message *msg = data;
got_data(msg->code);
schedule_work(&scp_work);
}
You get the cost of another register load here, but that should
be almost free.
There should probably also be some way to ensure that the amount
of data passed in the structure matches between mbox provider
and client.
> >> >> + do {
> >> >> +retry:
> >> >> + /* Wait until we get reply */
> >> >> + count = 0x1000000;
> >> >> + do {
> >> >> + cpu_relax();
> >> >> + val = readl_relaxed(
> >> >> + rx_reg + INTR_STAT_OFS);
> >> >> + } while (--count && !val);
> >> >> +
> >> >> + if (!val) {
> >> >> + pr_err("%s:%d SCB didn't reply\n",
> >> >> + __func__, __LINE__);
> >> >> + goto retry;
> >> >
> >> > It seems like this loop is unbounded and will just print an error every
> >> > 16M loops but never give up or re-enable interrupts if called with
> >> > interrupts disabled.
> >> >
> >> > It should probably be changed to either enforce being called with interrupts
> >> > enabled so you can call msleep() inbetween, or you should add error-handling
> >> > in case the remote side does not reply.
> >> >
> >> We can do that for completeness but otherwise my platform is as good
> >> as dead if the remote doesn't reply for some reason. And there is no
> >> fool-proof way to recover the state-machine from a failed
> >> communication.
> >
> > Do you know how long it takes normally? If you can prove that the
> > reply normally comes within a few microseconds, you can instead call
> > WARN_ON() once after too much time passes, and then continue polling.
> >
> > The case to avoid here is just accidentally polling for multiple
> > milliseconds with interrupts disabled, which would cause a lot of
> > problems.
> >
> From a few hundred micro-sec for CPU reset, to potentially tens of
> milli-sec for some I2C transaction ... yes we do have for I2C over
> mailbox! ;)
>
> Probably bailing out of the loop and returning -ETIMEOUT to the
> caller, before a WARN(), is the simplest way to die.
If you can have multiple miliseconds here, I think the code should
be changed to run in non-atomic context and use msleep(1) or
usleep_range() as a back-off. Is that possible?
> >> >> +struct mb86s7x_peri_clk {
> >> >> + u32 payload_size;
> >> >> + u32 cntrlr;
> >> >> + u32 domain;
> >> >> + u32 port;
> >> >> + u32 en;
> >> >> + u64 freqency;
> >> >> +} __packed;
> >> >
> >> > Just mark the last member by itself __packed. I assume you didn't
> >> > actually mean to change the alignment of the data structure to one
> >> > byte, but just want to say that the last one is misaligned.
> >> >
> >> This and others, are data packets that are passed between local and
> >> remote via SharedMemory. __packed is only meant to specify that these
> >> data structures have no holes in them.
> >
> > That would be '__packed __attribute__((aligned(4)))'. A struct of 'u32'
> > already has no padding on any architecture that is supported by Linux.
> > The only reason you need the packing here is because the u64 member is
> > unaligned. Note that marking the entire structure as packed means that
> > accesses are no longer atomic because the compiler may prefer to do them
> > one byte at a time, which can break the protocol on the shared memory
> > area.
> >
> We are not worried about the atomic access because the side sending
> the data doesn't touch it until the other side indicates it has
> consumed it.
It's still wrong though ;-)
Arnd
^ permalink raw reply
* [PATCH v2 00/14] AT91: PIT: Cleanups and move to drivers/clocksource
From: Maxime Ripard @ 2014-07-17 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C7A61C.7030704@linaro.org>
On Thu, Jul 17, 2014 at 12:31:56PM +0200, Daniel Lezcano wrote:
> On 07/17/2014 11:50 AM, Maxime Ripard wrote:
> >On Thu, Jul 10, 2014 at 09:51:05AM +0200, Maxime Ripard wrote:
> >>Hi Daniel,
> >>
> >>On Tue, Jul 01, 2014 at 11:33:13AM +0200, Maxime Ripard wrote:
> >>>Hi everyone,
> >>>
> >>>This series cleans up the PIT driver in order for it to not depend on
> >>>anything in mach-at91 anymore, and in the end move it out of
> >>>mach-at91.
> >>>
> >>>Along the way, these patches also do a bit of cleanup.
> >>>
> >>>This has been tested on a G45-EK without DT and an Xplained with DT.
> >>>
> >>
> >>Even though most of this patches are not clocksource related, it would
> >>be great if we could at least get an acked-by on the last patch that
> >>moves the driver to drivers/clocksource, since it pretty much becomes
> >>your burden :)
> >
> >Ping?
>
> Hi,
>
> I am in vacation right now. I will review the patches in the next two days.
Oh sorry then, enjoy your vacations :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/ebaabd91/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] i2c: efm32: correct namespacing of location property
From: Wolfram Sang @ 2014-07-17 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405068614-14279-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Fri, Jul 11, 2014 at 10:50:14AM +0200, Uwe Kleine-K?nig wrote:
> Olof Johansson pointed out that usually the company name is picked as
> namespace prefix to specific properties. So expect "energymicro,location"
> but fall back to the previously introduced name "efm32,location".
>
> Cc: Olof Johansson <olof@lixom.net>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Applied to for-next, thanks! If you think this is better suited in
for-current, let me know.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/8d55127a/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] irqchip: atmel-aic: Add irq RTC fixups
From: Jason Cooper @ 2014-07-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405016741-2407-1-git-send-email-boris.brezillon@free-electrons.com>
On Thu, Jul 10, 2014 at 08:25:38PM +0200, Boris BREZILLON wrote:
> Hello,
>
> This patch series introduce the notion of irq fixups for atmel SoCs.
>
> In most at91 SoCs the first interrupt line is shared by several IPs, and
> some of these HW blocks might be in an unknown state when booting the
> Linux kernel.
> Hence these IPs might generate spurious interrupts if they've not masked
> their irqs and the shared irq line is requested by another peripheral.
>
> These fixups were previously done in arch/arm/mach-at91/sysirq_mask.c
> but as we're trying to use standard implementation (IRQCHIP_DECLARE and
> automatic call of irqchip_init within arch/arm/kernel/irq.c) we need to
> do those fixups in the irqchip driver.
>
> This series only fix RTC irqs, but other HW blocks (RTT, PMC, ...) will
> be added later on.
>
> This series depends on this one [1].
>
> Best Regards,
>
> Boris
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271413.html
>
> Boris BREZILLON (3):
> irqchip: atmel-aic: Add irq fixup infrastructure
> irqchip: atmel-aic: Implement RTC irq fixup
> irqchip: atmel-aic: Define irq fixups for atmel SoCs
>
> drivers/irqchip/irq-atmel-aic-common.c | 47 ++++++++++++++++++++++++++++++++++
> drivers/irqchip/irq-atmel-aic-common.h | 4 +++
> drivers/irqchip/irq-atmel-aic.c | 15 +++++++++++
> drivers/irqchip/irq-atmel-aic5.c | 12 +++++++++
> 4 files changed, 78 insertions(+)
Whole series applied on top of irqchip/atmel-aic.
thx,
Jason.
^ permalink raw reply
* [PATCH v4 0/7] ARM: at91: move aic driver to drivers/irqchips
From: Jason Cooper @ 2014-07-17 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405012462-766-1-git-send-email-boris.brezillon@free-electrons.com>
On Thu, Jul 10, 2014 at 07:14:15PM +0200, Boris BREZILLON wrote:
> Hello,
>
> This series moves the AIC driver to the irqchip directory and make use of
> the generic chip framework whenever possible.
>
> This driver only support DT boards (all legacy board files should be soon
> replaced by their DT versions).
>
> Since the last version AIC and AIC5 code have been split and common
> functions have been moved to irq-atmel-aic-common.c.
> I know there is not much code in this file and it could have been
> duplicated in AIC and AIC5 drivers, but I'm planning to add more common
> stuff soon (AIC irq fixups previously done in
> arch/arm/mach-at91/sysirq_mask.c).
>
> Jason, if everybody is fine with this version could you share a topic
> branch containing patch 1 to 3 with Nicolas ?
I've now applied patches 1-3 to irqchip/atmel-aic. You can find the
branch here:
git://git.infradead.org/users/jcooper/linux.git irqchip/atmel-aic
It will be merged into -next today, and I'll merge it into irqchip/core
after a few days.
thx,
Jason.
^ permalink raw reply
* [PATCH 1/8] ARM: Add platform support for Fujitsu MB86S7X SoCs
From: Jassi Brar @ 2014-07-17 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5755738.IRCDfO2QJn@wuerfel>
On 16 July 2014 01:39, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 15 July 2014 23:07:58 Jassi Brar wrote:
>> >> diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
>> >> new file mode 100644
>> >> index 0000000..44f5b0c
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-mb86s7x/Kconfig
>> >> @@ -0,0 +1,18 @@
>> >> +config ARCH_MB86S7X
>> >> + bool "Fujitsu MB86S7x platforms" if (ARCH_MULTI_V7 && ARM_LPAE)
>> >> + select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
>> >
>> > Why the LPAE dependency? Is none of the RAM reachable by regular
>> > kernels?
>> >
>> Some devices like PCI, LLI need it and the S70-evb has half of its ram
>> above 4GB.
>> Maybe ARM_LPAE should be selected by inclusion of support for those?
>
> No, you can't select ARM_LPAE because that would break machines that
> do not support it in the same configuration.
>
To be clear, I meant selecting LPAE from config options specific to
S70-evb and PCI on S7x.
> Losing half the RAM or PCI should not be a problem, you'd just run
> with reduced functionality. You wouldn't want to do that in practice,
> but it's different from a hard dependency.
>
Sorry I am not sure what you mean. Is it ok as such?
>> >> +
>> >> +bool __init mb86s7x_smp_init_ops(void)
>> >> +{
>> >> + struct device_node *node;
>> >> +
>> >> + node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> >> + if (node && of_device_is_available(node)) {
>> >> + mcpm_smp_set_ops();
>> >> + return true;
>> >> + }
>> >> +
>> >> + return false;
>> >> +}
>> >
>> > Can you use the CPU_METHOD_OF_DECLARE() macro to set your
>> > SMP ops instead?
>> >
>> CPU_METHOD_OF_DECLARE() directly takes smp_ops but here we use mcpm's
>> smp_ops which are statically defined. We have to call
>> mcpm_smp_set_ops() which does the real job.
>
> Hmm, that seems like a hole in the API. Maybe you can come up with
> a solution for it that doesn't take too much effort. It seems the
> way that MCPM was integrated is suboptimal. We don't have too many
> users yet, can you try turning the logic for MCPM around so it fits
> the CPU_METHOD_OF_DECLARE()?
>
We could cook something up, but as Nico suggested a better place to
set mcpm ops is from where we do other other mcpm setup.
>> >> +static void __iomem *cmd_from_scb = MB86S7X_SHM_FROM_SCB_VIRT;
>> >> +static void __iomem *rsp_from_scb = MB86S7X_SHM_FROM_SCB_VIRT + 0x100;
>> >> +static void __iomem *cmd_to_scb = MB86S7X_SHM_FROM_SCB_VIRT + 0x200;
>> >> +static void __iomem *rsp_to_scb = MB86S7X_SHM_FROM_SCB_VIRT + 0x300;
>> >> +
>> >> +static LIST_HEAD(free_xfers);
>> >> +static LIST_HEAD(pending_xfers);
>> >> +static DEFINE_SPINLOCK(fsm_lock);
>> >> +static struct mbox_client mhu_cl;
>> >> +static struct mbox_chan *mhu_chan;
>> >> +static DECLARE_WORK(scb_work, try_xfer);
>> >> +static mhu_handler_t handler[MHU_NUM_CMDS];
>> >> +
>> >> +static enum {
>> >> + MHU_PARK = 0,
>> >> + MHU_WRR, /* Waiting to get Remote's Reply */
>> >> + MHU_WRL, /* Waiting to send Reply */
>> >> + MHU_WRRL, /* WAIT_Ra && WAIT_Rb */
>> >> + MHU_INVLD,
>> >> +} fsm_state;
>> >
>> > Ideally, these should all be part of a per-device data structure
>> > referenced from pdev_get_drvdata().
>> >
>> I saw that coming :)
>> We need this driver as early as when timers are populated and then for
>> secondary CPU power control ... when we don't have any platform_device
>> to hook the data on. And I think it is ok because this is the 'server'
>> driver for the platform which by definition won't have another
>> instance.
>
> Then for now put them into one local structure and pass around the
> pointer where you can but access the local one where it's too early.
>
> The effect will be the same, but it's easier to grasp by someone
> who is used to reading regular device drivers. Also add a comment
> in front of the data structure explaining the reasons for having
> a static copy.
>
OK
>> >> +static void got_data(u32 code)
>> >> +{
>> >> + struct completion *c = NULL;
>> >> + mhu_handler_t hndlr = NULL;
>> >> + unsigned long flags;
>> >> + int ev;
>> >> +
>> >> + if (code & RESP_BIT)
>> >> + ev = EV_RR;
>> >> + else
>> >> + ev = EV_RC;
>> >> +
>> >> + spin_lock_irqsave(&fsm_lock, flags);
>> >> +
>> >> + if (mhu_fsm[fsm_state][ev] == MHU_INVLD) {
>> >> + spin_unlock_irqrestore(&fsm_lock, flags);
>> >> + pr_err("State-%d EV-%d FSM Broken!\n", fsm_state, ev);
>> >> + return;
>> >> + }
>> >> + fsm_state = mhu_fsm[fsm_state][ev];
>> >> +
>> >> + if (code & RESP_BIT) {
>> >> + c = ax->c;
>> >> + memcpy_fromio(ax->buf, rsp_from_scb, ax->len);
>> >> + list_move(&ax->node, &free_xfers);
>> >> + ax = NULL;
>> >> + } else {
>> >> + /* Find and dispatch relevant registered handler */
>> >> + if (code < MHU_NUM_CMDS)
>> >> + hndlr = handler[code];
>> >> + if (!hndlr)
>> >> + pr_err("No handler for CMD_%u\n", code);
>> >> + }
>> >> +
>> >> + spin_unlock_irqrestore(&fsm_lock, flags);
>> >> +
>> >> + if (hndlr)
>> >> + hndlr(code, cmd_from_scb);
>> >> + if (c)
>> >> + complete(c);
>> >> +}
>> >> +
>> >> +static void mhu_recv(struct mbox_client *cl, void *data)
>> >> +{
>> >> + got_data((u32)data);
>> >> + schedule_work(&scb_work);
>> >> +}
>> >
>> > Why the cast between integer and pointer?
>> >
>> The common mailbox framework passes around pointers to data packets.
>> Its completely between controller and client drivers to decide the
>> format of the packet. In my case the packet is a simple u32 value.
>
> I don't think the mailbox framework should allow that much
> flexibility, because that would break portable drivers that
> rely on a particular behavior from the mailbox provider.
>
> I understand that your driver is not portable to another mailbox
> provider, but it still seems like a mistake in the API that should
> better be fixed sooner than later.
>
Here is what I remember of many discussions on the point over the last year :)
o We want to support zero-copy receives, which implies the mailbox
framework must simply forward the pointer to "data packet" from
controller to client driver.
o We could not think of a generic enough structure for 'data packet'
that could fit all protocols. So we assume the data packet format is
an explicit understanding between the controller(+remote) and the
client driver.
Or did I miss your point?
>> >> + do {
>> >> +retry:
>> >> + /* Wait until we get reply */
>> >> + count = 0x1000000;
>> >> + do {
>> >> + cpu_relax();
>> >> + val = readl_relaxed(
>> >> + rx_reg + INTR_STAT_OFS);
>> >> + } while (--count && !val);
>> >> +
>> >> + if (!val) {
>> >> + pr_err("%s:%d SCB didn't reply\n",
>> >> + __func__, __LINE__);
>> >> + goto retry;
>> >
>> > It seems like this loop is unbounded and will just print an error every
>> > 16M loops but never give up or re-enable interrupts if called with
>> > interrupts disabled.
>> >
>> > It should probably be changed to either enforce being called with interrupts
>> > enabled so you can call msleep() inbetween, or you should add error-handling
>> > in case the remote side does not reply.
>> >
>> We can do that for completeness but otherwise my platform is as good
>> as dead if the remote doesn't reply for some reason. And there is no
>> fool-proof way to recover the state-machine from a failed
>> communication.
>
> Do you know how long it takes normally? If you can prove that the
> reply normally comes within a few microseconds, you can instead call
> WARN_ON() once after too much time passes, and then continue polling.
>
> The case to avoid here is just accidentally polling for multiple
> milliseconds with interrupts disabled, which would cause a lot of
> problems.
>
>From a few hundred micro-sec for CPU reset, to potentially tens of
milli-sec for some I2C transaction ... yes we do have for I2C over
mailbox! ;)
Probably bailing out of the loop and returning -ETIMEOUT to the
caller, before a WARN(), is the simplest way to die.
>> >> +struct mb86s7x_peri_clk {
>> >> + u32 payload_size;
>> >> + u32 cntrlr;
>> >> + u32 domain;
>> >> + u32 port;
>> >> + u32 en;
>> >> + u64 freqency;
>> >> +} __packed;
>> >
>> > Just mark the last member by itself __packed. I assume you didn't
>> > actually mean to change the alignment of the data structure to one
>> > byte, but just want to say that the last one is misaligned.
>> >
>> This and others, are data packets that are passed between local and
>> remote via SharedMemory. __packed is only meant to specify that these
>> data structures have no holes in them.
>
> That would be '__packed __attribute__((aligned(4)))'. A struct of 'u32'
> already has no padding on any architecture that is supported by Linux.
> The only reason you need the packing here is because the u64 member is
> unaligned. Note that marking the entire structure as packed means that
> accesses are no longer atomic because the compiler may prefer to do them
> one byte at a time, which can break the protocol on the shared memory
> area.
>
We are not worried about the atomic access because the side sending
the data doesn't touch it until the other side indicates it has
consumed it.
thanks
jassi
^ permalink raw reply
* [PATCH] irqchip: gic: Add binding probe for ARM GIC400
From: Mark Rutland @ 2014-07-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2621565.f5eISveXXJ@diego>
On Mon, Jul 14, 2014 at 11:03:03PM +0100, Heiko St?bner wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the
> "arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE
> was never added to the gic driver.
>
> Therefore add the missing irqchip declaration for it.
>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> Removed additional empty line and adapted commit message to mark it
> as fixing an issue.
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> As I really need this, I took the liberty of adapting the patch accordingly
> to make it apply on top of the current irqchip/for-next (or urgent) and
> explicitly state the fixed issue. Hope that is ok
While this is a fix that we should have, I'm not certain I see why this
is urgent. A dt can already have:
compatible = "arm,gic-400", "arm,cortex-a15-gic";
Which will work _today_, before this patch. If we need to treat the A15
GIC string differently, we'll have to ensure we support the GIC 400
string first.
Thanks,
Mark.
>
> drivers/irqchip/irq-gic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 9d26643..6ff28b4 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -1020,6 +1020,7 @@ gic_of_init(struct device_node *node, struct device_node *parent)
> gic_cnt++;
> return 0;
> }
> +IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
> IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
> IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
> IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
> --
> 1.9.0
>
>
>
>
^ permalink raw reply
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Jason Cooper @ 2014-07-17 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404947104-21345-1-git-send-email-suravee.suthikulpanit@amd.com>
On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> This patch set introduces support for MSI(-X) in GICv2m specification,
> which is implemented in some variation of GIC400.
>
> This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> (https://lkml.org/lkml/2014/3/14/320).
>
> Changes in V3:
> * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
> (per Jason Cooper request)
> * Misc fix/clean up per Mark Rutland comments
> * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
> * Patch 4 is new to the series:
> * Add ARM64-specific version arch_setup_msi_irqs() to allow support
> for Multiple MSI.
> * Add support for Multiple MSI for GICv2m.
>
> Suravee Suthikulpanit (4):
> irqchip: gic: Add binding probe for ARM GIC400
> irqchip: gic: Restructuring ARM GIC code
> irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
irqchip/gic with irqchip/urgent merged in. To facilitate
testing/merging, I've prepared an unsigned tag for you on the
irqchip/gic branch:
git://git.infradead.org/users/jcooper/linux.git tags/deps-irqchip-gic-3.17-2
Unless you tell me I broke something horribly, this tag and irqchip/gic
up to that point are stable.
thx,
Jason.
^ permalink raw reply
* [PATCH 3/4 V3] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
From: Mark Rutland @ 2014-07-17 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404947104-21345-4-git-send-email-suravee.suthikulpanit@amd.com>
Hi Suravee,
Apologies for the late reply on this one. I was hoping that Marc would
be able to take another look at this, but he's away at present.
On Thu, Jul 10, 2014 at 12:05:03AM +0100, suravee.suthikulpanit at amd.com wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> ARM GICv2m specification extends GICv2 to support MSI(-X) with
> a new set of register frames. This patch introduces support for
> the non-secure GICv2m register frame.
>
> The driver currently matchs "arm,gic-400-plus" in device tree binding,
> which implements GICv2m.
>
> The "msi-controller" keyword in ARM GIC devicetree binding is used to indentify
> GIC driver that it should enable MSI(-X) support, The region of GICv2m MSI
> register frame is specified using the register frame index 4 in the device tree.
> MSI support is optional.
>
> Each GIC maintains an "msi_chip" structure. To discover the msi_chip,
> PCI host driver can do the following:
>
> struct device_node *gic_node = of_irq_find_parent(pdev->dev.of_node);
> pcie_bus->msi_chip = of_pci_find_msi_chip_by_node(gic_node);
>
> Cc: Mark Rutland <Mark.Rutland@arm.com>
> Cc: Marc Zyngier <Marc.Zyngier@arm.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 20 +-
> arch/arm64/Kconfig | 1 +
> drivers/irqchip/Kconfig | 7 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-gic-v2m.c | 251 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v2m.h | 13 ++
> drivers/irqchip/irq-gic.c | 23 ++-
> drivers/irqchip/irq-gic.h | 31 +++-
> 8 files changed, 334 insertions(+), 13 deletions(-)
> create mode 100644 drivers/irqchip/irq-gic-v2m.c
> create mode 100644 drivers/irqchip/irq-gic-v2m.h
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 5573c08..d2eea0b 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -12,11 +12,14 @@ Main node required properties:
>
> - compatible : should be one of:
> "arm,gic-400"
> + "arm,gic-400-v2m"
I'm still not entirely comfortable about this, as I was under the
impression that the MSI frame was a block on the side of the GIC rather
than being a composite entity with the rest of the GIC.
Which means that it would be entirely possible to attach multiple copies
of that block, which this binding doesn't cover.
> "arm,cortex-a15-gic"
> "arm,cortex-a9-gic"
> "arm,cortex-a7-gic"
> "arm,arm11mp-gic"
> +
> - interrupt-controller : Identifies the node as an interrupt controller
> +
> - #interrupt-cells : Specifies the number of cells needed to encode an
> interrupt source. The type shall be a <u32> and the value shall be 3.
>
> @@ -37,9 +40,16 @@ Main node required properties:
> the 8 possible cpus attached to the GIC. A bit set to '1' indicated
> the interrupt is wired to that CPU. Only valid for PPI interrupts.
>
> -- reg : Specifies base physical address(s) and size of the GIC registers. The
> - first region is the GIC distributor register base and size. The 2nd region is
> - the GIC cpu interface register base and size.
> +- reg : Specifies base physical address(s) and size of the GIC register frames.
> +
> + Region | Description
> + Index |
> + -------------------------------------------------------------------
> + 0 | GIC distributor register base and size
> + 1 | GIC cpu interface register base and size
> + 2 | VGIC interface control register base and size (Optional)
> + 3 | VGIC CPU interface register base and size (Optional)
> + 4 | GICv2m MSI interface register base and size (Optional)
And describing it as a separate (but related) component would get around
the issue of orthogonality with the GICV and GICH registers.
Nit: can we use the architected prefixes here please? GICC, GICD, GICH,
and GICV respectively for indexes 0-3.
Cheers,
Mark.
^ permalink raw reply
* [PATCH 1/3] ARM: EXYNOS: Move code from hotplug.c to platsmp.c
From: Tomasz Figa @ 2014-07-17 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405520417-15027-1-git-send-email-k.kozlowski@samsung.com>
Hi Krzysztof,
On 16.07.2014 16:20, Krzysztof Kozlowski wrote:
> Cleanup a little the SMP/hotplug code for Exynos by:
> 1. Moving completely all functions from hotplug.c into the platsmp.c;
> 2. Deleting the hotplug.c file.
>
> After recent cleanups (e.g. 75ad2ab28f0f "ARM: EXYNOS: use
> v7_exit_coherency_flush macro for cache disabling") there was only CPU
> power down related code in hotplug.c file. Keeping this file does not
> give any benefits.
>
> The commit only moves code around with one additional observable change:
> the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These
> CFLAGS are not necessary any more.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> ---
> arch/arm/mach-exynos/Makefile | 3 --
> arch/arm/mach-exynos/common.h | 2 -
> arch/arm/mach-exynos/hotplug.c | 92 ------------------------------------------
> arch/arm/mach-exynos/platsmp.c | 74 +++++++++++++++++++++++++++++++++
> 4 files changed, 74 insertions(+), 97 deletions(-)
> delete mode 100644 arch/arm/mach-exynos/hotplug.c
>
For this and remaining patches from this series:
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
--
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 3/4 V3] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
From: Jason Cooper @ 2014-07-17 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404947104-21345-4-git-send-email-suravee.suthikulpanit@amd.com>
On Wed, Jul 09, 2014 at 06:05:03PM -0500, suravee.suthikulpanit at amd.com wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> ARM GICv2m specification extends GICv2 to support MSI(-X) with
> a new set of register frames. This patch introduces support for
> the non-secure GICv2m register frame.
>
> The driver currently matchs "arm,gic-400-plus" in device tree binding,
> which implements GICv2m.
>
> The "msi-controller" keyword in ARM GIC devicetree binding is used to indentify
> GIC driver that it should enable MSI(-X) support, The region of GICv2m MSI
> register frame is specified using the register frame index 4 in the device tree.
> MSI support is optional.
>
> Each GIC maintains an "msi_chip" structure. To discover the msi_chip,
> PCI host driver can do the following:
>
> struct device_node *gic_node = of_irq_find_parent(pdev->dev.of_node);
> pcie_bus->msi_chip = of_pci_find_msi_chip_by_node(gic_node);
>
> Cc: Mark Rutland <Mark.Rutland@arm.com>
> Cc: Marc Zyngier <Marc.Zyngier@arm.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 20 +-
> arch/arm64/Kconfig | 1 +
> drivers/irqchip/Kconfig | 7 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-gic-v2m.c | 251 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v2m.h | 13 ++
> drivers/irqchip/irq-gic.c | 23 ++-
> drivers/irqchip/irq-gic.h | 31 +++-
> 8 files changed, 334 insertions(+), 13 deletions(-)
> create mode 100644 drivers/irqchip/irq-gic-v2m.c
> create mode 100644 drivers/irqchip/irq-gic-v2m.h
Applied to irqchip/gic with some minor typos fixed in the commit
message.
thx,
Jason.
^ permalink raw reply
* [PATCH 2/4 V3] irqchip: gic: Restructuring ARM GIC code
From: Jason Cooper @ 2014-07-17 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404947104-21345-3-git-send-email-suravee.suthikulpanit@amd.com>
On Wed, Jul 09, 2014 at 06:05:02PM -0500, suravee.suthikulpanit at amd.com wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> This patch restructures the code to prepare for future MSI support.
> It moves the declaration of structures and functions into the header file,
> and omit the static prefix.
>
> Since we are planing to have different irq_chip for GICv2m, the patch adds
> irq_chip pointer in the gic_chip_data which is initialized during probing phase.
>
> This should not have any functional changes.
>
> Cc: Mark Rutland <Mark.Rutland@arm.com>
> Cc: Marc Zyngier <Marc.Zyngier@arm.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
> drivers/irqchip/irq-gic.c | 65 +++++++++++++++++++++--------------------------
> drivers/irqchip/irq-gic.h | 52 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 81 insertions(+), 36 deletions(-)
> create mode 100644 drivers/irqchip/irq-gic.h
Applied to irqchip/gic. With a dependency on irqchip/urgent for
144cb08864ed irqchip: gic: Add binding probe for ARM GIC400
As a result, I had to hand-jam the last hunk for irq-gic.c. Please
double-check my work.
thx,
Jason.
^ permalink raw reply
* [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
From: Russell King - ARM Linux @ 2014-07-17 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6510599.Qoc205T3v7@wuerfel>
On Thu, Jul 17, 2014 at 02:39:42PM +0200, Arnd Bergmann wrote:
> On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> > No - the problem is that we're running from the page table in question
> > with global mappings, and we need to switch all these mappings, including
> > the ones we're currently using to execute from.
> >
> > We can't even create a new page table and switch to it because the
> > mappings in question are global mappings.
> >
> > The only way to do that safely from an architectural point of view would
> > be to turn the MMU off, and drop back to assembly code to change the
> > page tables, and re-enable the MMU. For something as obscure as Marvell's
> > coherency stuff, that's not something I want to see in core code.
>
> Is this different from what we do in the LPAE version of
> early_paging_init()? That code already adjusts all the page
> table entries on a per-platform setting and should be very
> easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
> and possibly able to extend for traditional (non-LPAE)
> page tables without a lot of duplication.
I'm going to have to profess no knowledge of how the LPAE stuff works.
LPAE is something I can't run, and something that I was not involved
in its creation. Therefore, I know very little about it and zero
experience thereof.
>From a glance over that function, I think that is unsafe for all the
reasons I've stated. However, I'll pass this over to Will Deacon
to comment further on.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 0/7] i2c: Relax mandatory I2C ID table passing
From: Wolfram Sang @ 2014-07-17 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717102342.GD30888@lee--X1>
On Thu, Jul 17, 2014 at 11:23:42AM +0100, Lee Jones wrote:
> Hi Wolfram,
>
> Are you going to take a lot at this set?
Sure thing, yet I won't make it for 3.17, sadly :( It has high priority
for 3.18, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/e406f73f/attachment.sig>
^ permalink raw reply
* [PATCH 7/8] mailbox: f_mhu: add driver for Fujitsu MHU controller
From: Jassi Brar @ 2014-07-17 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C7A5F1.30209@arm.com>
On 17 July 2014 16:01, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 17/07/14 07:25, Jassi Brar wrote:
>>
>>>
>>>> + u32 val;
>>>> +
>>>> + pr_debug("%s:%d\n", __func__, __LINE__);
>>>
>>>
>>>
>>> Please remove all these debug prints.
>>>
>> These are as good as absent unless DEBUG is defined.
>>
>
> Yes, but with mailbox framework, the controller driver(esp. this one)is
> almost like a shim layer. Instead of each driver adding these debugs,
> IMO it would be good to have these in the framework.
>
OK
>>>
>>>> + /* See NOTE_RX_DONE */
>>>> + val = readl_relaxed(mlink->rx_reg + INTR_STAT_OFS);
>>>> + mbox_chan_received_data(chan, (void *)val);
>>>> +
>>>> + /*
>>>> + * It is agreed with the remote firmware that the receiver
>>>> + * will clear the STAT register indicating it is ready to
>>>> + * receive next data - NOTE_RX_DONE
>>>> + */
>>>
>>>
>>> This note could be added as how this mailbox works in general and
>>> it's not just Rx right ? Even Tx done is based on this logic.
>>> Basically the logic is valid on both directions.
>>>
>> Yes that is a protocol level agreement. Different f/w may behave
>> differently.
>>
>
> Ok, I am not sure if that's entirely true because the MHU spec says it
> drives
> the signal using a 32-bit register, with all 32 bits logically ORed
> together.
> Usually only Rx signals are wired to interrupts and Tx needs to be polled
> but that's entirely implementation choice I believe.
>
On my platform, _STAT register only carries the command code but
actual data is exchanged via SharedMemory/SHM. Now we need to know
when the sent data packet (in SHM) has been consumed by the remote -
for which our protocol mandates the remote clear the TX_STAT register.
And vice-versa for RX.
Some other f/w may choose some other mechanism for TX-Done - say some
ACK bit set or even some time bound guarantee.
> More over if it's protocol level agreement it should not belong here :)
>
My f/w expects the RX_STAT cleared after reading data from SHM. Where
do you think is the right place to clear RX_STAT?
I have said many times in many threads... its the mailbox controller
_and_ the remote f/w that should be seen as one entity. It may not be
possible to write a controller driver that works with any remote
firmware.
>
>>>> +static int mhu_startup(struct mbox_chan *chan)
>>>> +{
>>>> + struct mhu_link *mlink = (struct mhu_link *)chan->con_priv;
>>>> + unsigned long flags;
>>>> + u32 val;
>>>> + int ret;
>>>> +
>>>> + pr_debug("%s:%d\n", __func__, __LINE__);
>>>> + spin_lock_irqsave(&mlink->lock, flags);
>>>> + val = readl_relaxed(mlink->tx_reg + INTR_STAT_OFS);
>>>> + writel_relaxed(val, mlink->tx_reg + INTR_CLR_OFS);
>>>> + spin_unlock_irqrestore(&mlink->lock, flags);
>>>> +
>>>> + ret = request_irq(mlink->irq, mhu_rx_interrupt,
>>>> + IRQF_SHARED, "mhu_link", chan);
>>>
>>>
>>>
>>> Just a thought: Can this be threaded_irq instead ?
>>> Can move request_irq to probe instead esp. if threaded_irq ?
>>> That provides some flexibility to client's rx_callback.
>>>
>> This is controller driver, and can not know which client want
>> rx_callback in hard-irq context and which in thread_fn context.
>> Otherwise, request_irq() does evaluate to request_threaded_irq(), if
>> thats what you mean.
>
> Agreed but on contrary since MHU involves external firmware(running
> on different processor) which might have it's own latency, I prefer
> threaded over hard irq. And yes request_irq does evaluate to
> request_threaded_irq but with thread_fn = NULL which is not what I want.
>
If remote has its own latency, that does not mean we add some more :)
>> There might be use-cases like (diagnostic or other) data transfer
>> over mailbox where we don't wanna increase latency, so we have to
>> provide a rx_callback in hard-irq context.
>>
> OK
>
Cool.
>
>>>
>>>> + for (i = 0; i < 3; i++) {
>>>> + mhu->chan[i].con_priv = &mhu->mlink[i];
>>>> + spin_lock_init(&mhu->mlink[i].lock);
>>>> + res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
>>>> + mhu->mlink[i].irq = res->start;
>>>> + mhu->mlink[i].rx_reg = mhu->base + mhu_reg[i];
>>>> + mhu->mlink[i].tx_reg = mhu->mlink[i].rx_reg + 0x100;
>>>> + }
>>>> +
>>>> + mhu->mbox.dev = &pdev->dev;
>>>> + mhu->mbox.chans = &mhu->chan[0];
>>>> + mhu->mbox.num_chans = 3;
>>>
>>>
>>>
>>> Change this to 2, we shouldn't expose secular channel here as Linux can't
>>> access that anyway.
>>>
>> On the contrary, I think the device driver code should be able to
>> manage every resource - secure or non-secure. If we remove secure
>> channel option, what do we do on some other platform that needs it?
>> And Linux may not always run in non-secure mode.
>
>
> In general secure accesses are avoided these days in Linux as we have no
> way to identify it. I agree there are few place where we do access.
> Even though I don't like you have secure channel access in Linux, you
> have valid reasons. In case you decide to support it, there is some
> restrictions in bit 31, though RAZ/WI you need to notify that to protocol
> if it tries to access it ?
>
>
>> So here we populate all channels and let the clients knows which
>> channel to use via platform specific details - DT. Please note the
>> driver doesn't touch any secure resource if client doesn't ask it to
>> (except SCFG for now, which I think should have some S vs NS DT
>> binding).
>>
>
> Not sure of this though. We need feedback from DT maintainers.
>
Yup.
Cheers,
Jassi
^ permalink raw reply
* [PATCH 4/4 V3] irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
From: Jason Cooper @ 2014-07-17 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404947104-21345-5-git-send-email-suravee.suthikulpanit@amd.com>
Suravee,
On Wed, Jul 09, 2014 at 06:05:04PM -0500, suravee.suthikulpanit at amd.com wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> This patch extend GICv2m MSI to support multiple MSI in ARM64.
>
> This requires the common arch_setup_msi_irqs() to be overwriten
> with ARM64 version which does not return 1 for PCI_CAP_ID_MSI and
> nvec > 1.
>
> Cc: Mark Rutland <Mark.Rutland@arm.com>
> Cc: Marc Zyngier <Marc.Zyngier@arm.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
> arch/arm64/include/asm/msi.h | 15 ++++++++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/msi.c | 57 ++++++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v2m.c | 80 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 153 insertions(+)
> create mode 100644 arch/arm64/include/asm/msi.h
> create mode 100644 arch/arm64/kernel/msi.c
With the Subject line nit fixed ("irqchip: gic-v2m: ..."),
Acked-by: Jason Cooper <jason@lakedaemon.net>
Please route as you see fit.
thx,
Jason.
^ permalink raw reply
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Jason Cooper @ 2014-07-17 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C3FE7D.3090805@amd.com>
On Mon, Jul 14, 2014 at 10:59:57AM -0500, Suravee Suthikulanit wrote:
> On 7/13/2014 6:14 PM, Jason Cooper wrote:
> >Suravee,
> >
> >On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> >>From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >>
> >>This patch set introduces support for MSI(-X) in GICv2m specification,
> >>which is implemented in some variation of GIC400.
> >>
> >>This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> >>(https://lkml.org/lkml/2014/3/14/320).
> >
> >Grrr. I mis-spoke against your v1 of this series. There are more
> >changes to irq-gic.c than I originally thought in this series.
>
> I am not quite sure what your are referring to.
>
No problem, it was an old comment. If you weren't depending on it then it
doesn't matter. ;-)
> >Additionally, we have a lot of other significant changes to that driver
> >as well this cycle. It would be really helpful if I could take patches
> >1-3 through irqchip/gic. I can Ack #4 with the Subject change, and the
> >branch it lands in can depend on irqchip/gic, no problem there.
>
> Patch 1-3 should be able to go through the irqchip/gic along with
> the gicv3 from Marc, which I have rebased this patch against.
Perfect!
> Patch 4 is arch64 architectural changes. Therefore, it might need
> to be going through a different branch. Marc/Mark/Will/Catalin, do
> you have any suggestions on which branch this should go to?
Yep, I'll Ack it for arm64 to take, conflicts should be minimal.
thx,
Jason.
^ permalink raw reply
* [PATCH] irqchip: gic: Add binding probe for ARM GIC400
From: Jason Cooper @ 2014-07-17 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2621565.f5eISveXXJ@diego>
On Tue, Jul 15, 2014 at 12:03:03AM +0200, Heiko St?bner wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the
> "arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE
> was never added to the gic driver.
>
> Therefore add the missing irqchip declaration for it.
>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> Removed additional empty line and adapted commit message to mark it
> as fixing an issue.
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> As I really need this, I took the liberty of adapting the patch accordingly
> to make it apply on top of the current irqchip/for-next (or urgent) and
> explicitly state the fixed issue. Hope that is ok
>
> drivers/irqchip/irq-gic.c | 1 +
> 1 file changed, 1 insertion(+)
Applied to irqchip/urgent with Will's Ack and Cc'd to stable for v3.14+
thx,
Jason.
^ permalink raw reply
* [RFC/PATCH 0/5] Add Video Processing Front End Support
From: Prabhakar Lad @ 2014-07-17 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405447012-5340-1-git-send-email-balbi@ti.com>
On Tue, Jul 15, 2014 at 6:56 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi all,
>
> the following patches add suport for AM43xx's Video Processing
> Front End (VPFE). Full documentation is available at [1] chapter 14.
>
> This driver has been tested with linux-next from yesterday, plus my
> (already queued) am437x starter kit patches, plus these patches, plus
> the sensor driver which, saddly enough, we're not allowed to release :-(
>
> This driver has almost full v4l2-compliance with only 2 failures (I'll
> take hints on how to properly fix them) as below:
>
> fail: v4l2-compliance.cpp(419): !doioctl(node2,
> VIDIOC_S_PRIORITY, &prio)
> test VIDIOC_G/S_PRIORITY: FAIL
>
> fail: v4l2-test-formats.cpp(319): pixelformat !=
> V4L2_PIX_FMT_JPEG && colorspace ==
> V4L2_COLORSPACE_JPEG
> fail: v4l2-test-formats.cpp(418):
> testColorspace(pix.pixelformat, pix.colorspace)
> test VIDIOC_G_FMT: FAIL
>
> I have also tested with gst-launch using fbdevsink and I can see my
> ugly mug just fine.
>
> Please give this a thorough review and let me know of any problems
> which need to be sorted out and I'll try to help out as time allows.
>
> cheers
>
> [1] http://www.ti.com/lit/pdf/spruhl7
>
> Benoit Parrot (4):
> Media: platform: Add ti-vpfe driver for AM437x device
> arm: omap: hwmod: add hwmod entries for AM437x VPFE
> arm: boot: dts: am4372: add vpfe DTS entries
> arm: dts: am43x-epos: Add VPFE DTS entries
>
> Darren Etheridge (1):
> ARM: dts: am437x-sk-evm: add vpfe support and ov2659 sensor
>
> arch/arm/boot/dts/am4372.dtsi | 16 +
> arch/arm/boot/dts/am437x-sk-evm.dts | 63 +
> arch/arm/boot/dts/am43x-epos-evm.dts | 54 +
> arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56 +
> arch/arm/mach-omap2/prcm43xx.h | 3 +-
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/ti-vpfe/Kconfig | 12 +
> drivers/media/platform/ti-vpfe/Makefile | 2 +
> drivers/media/platform/ti-vpfe/am437x_isif.c | 1053 +++++++++
> drivers/media/platform/ti-vpfe/am437x_isif.h | 355 +++
> drivers/media/platform/ti-vpfe/am437x_isif_regs.h | 144 ++
> drivers/media/platform/ti-vpfe/vpfe_capture.c | 2478 +++++++++++++++++++++
> drivers/media/platform/ti-vpfe/vpfe_capture.h | 263 +++
> 14 files changed, 4501 insertions(+), 1 deletion(-)
Missing documentation for DT ?
Thanks,
--Prabhakar Lad
> create mode 100644 drivers/media/platform/ti-vpfe/Kconfig
> create mode 100644 drivers/media/platform/ti-vpfe/Makefile
> create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.c
> create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.h
> create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif_regs.h
> create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.c
> create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.h
>
> --
> 2.0.0.390.gcb682f8
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
From: Arnd Bergmann @ 2014-07-17 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717083342.GS21766@n2100.arm.linux.org.uk>
On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> On Thu, Jul 17, 2014 at 10:24:25AM +0200, Thomas Petazzoni wrote:
> > If I understand correctly, we are already changing the page tables
> > anyway, to switch certain pages to be mapped uncached, to do DMA
> > coherent allocations, no?
>
> I've no idea, I never looked at that code. I hope that Marek has
> considered the requirements of the architecture when creating that
> code...
>
> > So wouldn't it be possible to keep the early
> > assembly code as it is today, and then later, in C code, once we have
> > identified the platform on which we're running, modify the page tables
> > to switch to the appropriate page attributes (write allocate cache
> > policy, shareable attribute, etc.) ?
>
> No - the problem is that we're running from the page table in question
> with global mappings, and we need to switch all these mappings, including
> the ones we're currently using to execute from.
>
> We can't even create a new page table and switch to it because the
> mappings in question are global mappings.
>
> The only way to do that safely from an architectural point of view would
> be to turn the MMU off, and drop back to assembly code to change the
> page tables, and re-enable the MMU. For something as obscure as Marvell's
> coherency stuff, that's not something I want to see in core code.
Is this different from what we do in the LPAE version of
early_paging_init()? That code already adjusts all the page
table entries on a per-platform setting and should be very
easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
and possibly able to extend for traditional (non-LPAE)
page tables without a lot of duplication.
At the moment it only handles a platform-specific undetectable
PHYS_OFFSET for mach-keystone, which to me sounds equally
hacky as the platform-specific undetectable pmdprot value
for mvebu.
Is there anything I'm missing why one works and the other doesn't?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT changes for v3.17
From: Jason Cooper @ 2014-07-17 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140708124653.GX23978@titan.lakedaemon.net>
Russell,
On Tue, Jul 08, 2014 at 08:46:53AM -0400, Jason Cooper wrote:
> On Tue, Jul 08, 2014 at 01:12:52PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 08, 2014 at 07:57:27AM -0400, Jason Cooper wrote:
> > > Can you offer any suggestions as to how you would like this resolved? I
> > > thought when I voiced my opinion as above, and Russell didn't reply,
> > > there was implied acknowledgement...
> >
> > I didn't reply probably because I didn't see the message and/or I'm busy
> > with other stuff.
>
> Fair enough.
This is the second time I've asked you for a technical reason not to
merge these DTS patches, only to be met with silence, again.
> > I know that Sebastian asked Rabeeh on IRC yesterday whether the flash
> > chip type could be used to detect the difference between the two, but
> > has not yet received an answer.
>
> Ok.
>
> > As the two DT descriptions are mutually incompatible, there isn't much
> > choice. And (afaik) there's no choice of updating the boot loader to
> > a version which can deal with DT - yes it may be u-boot, but I've no
> > idea if modern u-boot works on it, and I really would not like to try.
>
> Right, what I'm arguing for (since trimmed), is *not* bootloader
> upgrades. I think Sebastian's changes are ok because:
>
> - Most users have production boxes (Sebastian's patches provide their
> sane default)
>
> - Most users of mainline or distro kernels are appending the dtb, so
> swapping out a dtb, while not ideal, isn't earth-shattering.
>
> The *only* failure condition I can see is what you already highlighted,
> people who don't know they have an engineering sample. Sebastian's
> patches work for most people, and on the odd chance of the failure, the
> user simply appends the other dtb and reboots.
>
> Once we hear back from Rabeeh, at a minimum, we'll add a comment to the
> dts file for distro maintainers and users to find. If possible, we'll
> add a hook in arch code to read from SPI and adjust the dtb accordingly.
Either of these solutions will be follow-on patches. There's no need to
hold up this pull request over this information.
> In either case, comment or code, the dts files changed in this series
> are correct and won't change.
I still stand by this.
> I'm sorry to be dense, Russell, but what am I missing from your
> objection?
Olof, Arnd, please merge this request. I can re-send if you need.
We have more changes pending in mvebu/dt on top of this, and we're
getting very close to the cutoff for the merge window.
thx,
Jason.
^ permalink raw reply
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Will Deacon @ 2014-07-17 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8wZ9z8+0Q-2D_B3tkuQnksdWFeWEAadkHyB72oS6ae=A@mail.gmail.com>
On Thu, Jul 17, 2014 at 12:12:48PM +0100, Peter Maydell wrote:
> On 17 July 2014 11:54, Will Deacon <will.deacon@arm.com> wrote:
> > I don't really see the benefits of pretending that /proc/cpuinfo is remotely
> > portable between architectures.
>
> I'm not suggesting it's portable. I'm suggesting that you need
> a good reason to push backwards against a design decision
> made on other architectures. In particular, given that ARM is
> in general *more* likely to be heterogenous than x86 (given
> the existence of big.LITTLE), it seems baffling to try to move
> in a direction that denies the possibility of further heterogeneity
> in future.
We're not denying the possibility of heterogeneity, we're trying to expose a
consistent view of the system to userspace. Differences between cores should
be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly
passed off to userspace.
> > So the real question is: do we want to allow Linux to support features that
> > exist only on a subset of cores in the system? The current thinking is that
> > we truncate the advertised features to the common system subset, which means
> > it will be the same on all cores, by definition. That allows hardware guys
> > to build crazy systems that we can at least use, without imparting a world
> > of pain onto software that needs to run on them.
>
> I've already made one suggestion (non-pervasive crypto).
> You could also envisage "feature bits" that effectively mean
> "things will be faster on this core" even if they still work on
> other cores too.
I don't believe that knowledge belongs in userspace. If you wanted to
support crypto on such a system, then you advertise it as a system feature
and migrate those tasks to the cores that support the instructions (in a
similar manner to migrating the FPU on architecture that can share one).
However, I'd prefer to start from a point where we *don't*' support such
systems and actively dissuage people from building them.
> > I also think that we're backed into a corner regardless. We've seen how
> > people ignore hwcaps (e.g. SWP), so they're likely to parse the caps for
> > CPU0 and use that as an indication of the system capabilities.
>
> Certainly userspace *can* do the wrong thing. That doesn't
> necessarily mean that the kernel should only ever provide the
> API equivalent of safety scissors...
Userspace *will* do the wrong thing and it *will* turn the feature into
useless baggage that we have to carry.
> > Note that the features list *isn't* just the features supported by the CPU.
> > It also takes into account the set of features supported by the kernel (e.g.
> > we don't advertise VFP on ARMv7 if VFP context switching isn't enabled).
>
> This is an argument for also advertising the lowest-common-denominator
> feature bits. (Do you want to argue for a single "features:" line
> plus per-core "extra-features:" lines?)
That's what Ard brought up and I think it makes more sense that printing the
same features line for each core. However, I question its usefulness and
think it's ripe for misuse.
Will
^ permalink raw reply
* [PATCH] [RFC] [media] omap3isp: try to fix dependencies
From: Laurent Pinchart @ 2014-07-17 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46586956.hxqoJOmDbk@wuerfel>
Hi Arnd,
Sorry for the late reply.
On Friday 13 June 2014 14:02:01 Arnd Bergmann wrote:
> commit 2a0a5472af5c ("omap3isp: Use the ARM DMA IOMMU-aware operations")
> brought the omap3isp driver closer to using standard APIs, but also
> introduced two problems:
>
> a) it selects a particular IOMMU driver for no good reason. This just
> causes hard to track dependency chains, in my case breaking an
> experimental patch set that tries to reenable !MMU support on ARM
> multiplatform kernels. Since the driver doesn't have a dependency
> on the actual IOMMU implementation (other than sitting on the same
> SoC), this changes the 'select OMAP_IOMMU' to a generic 'depends on
> IOMMU_API' that reflects the actual usage.
That sounds good to me.
> b) The driver incorrectly calls into low-level helpers designed to
> be used by the IOMMU implementation:
> arm_iommu_{create,attach,release}_mapping.
I agree with you, and that's my plan, but I haven't been able to fix the
problem yet. It's somewhere on my (too big) to-do list.
Please note that, while the problem hasn't been introduced by commit
2a0a5472af5c, the driver was in an even worse shape before that, as it called
in the OMAP IOMMU driver directly.
> I'm not fixing this here, but adding a FIXME and a dependency on
> ARM_DMA_USE_IOMMU. I believe the correct solution is to move the calls
> into the omap iommu driver that currently doesn't have them, and change
> the isp driver to call generic functions.
OMAP_IOMMU doesn't select ARM_DMA_USE_IOMMU :-/ That should be fixed first,
otherwise the OMAP3 ISP driver won't be available at all.
> In addition, this also adds the missing 'select VIDEOBUF2_DMA_CONTIG'
> that is needed since fbac1400bd1 ("[media] omap3isp: Move to videobuf2")
That's already fixed in my tree, so I'll skip that part.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> ----
>
> Hi Laurent,
>
> Could you have a look at this? It's possible I'm missing something
> important here, but this is what I currently need to get randconfig
> builds to use the omap3isp driver.
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 8108c69..15bf61b 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -94,8 +94,9 @@ config VIDEO_M32R_AR_M64278
> config VIDEO_OMAP3
> tristate "OMAP 3 Camera support"
> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> - select ARM_DMA_USE_IOMMU
> - select OMAP_IOMMU
> + depends on ARM_DMA_USE_IOMMU # FIXME: use iommu API instead of low-level
> ARM calls + depends on IOMMU_API
> + select VIDEOBUF2_DMA_CONTIG
> ---help---
> Driver for an OMAP 3 camera controller.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/4] mips: Add cma support to mips
From: Marek Szyprowski @ 2014-07-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405525892-60383-1-git-send-email-Zubair.Kakakhel@imgtec.com>
Hello,
On 2014-07-16 17:51, Zubair Lutfullah Kakakhel wrote:
> Here we have 4 patches that add cma support to mips.
>
> Patch 1 adds dma-contiguous.h to asm-generic
> Patch 2 and 3 make arm64 and x86 use dma-contiguous from asm-generic
> Patch 4 adds cma to mips.
>
> I'd like to request ralf to take these set of 4 patches via his tree.
>
> acks from asm-generic, arm64 and x86 welcome.
>
> patches based on linux-next b997a07604562f1a54cc531fe1cf7447f0ed6078
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Zubair Lutfullah Kakakhel (4):
> asm-generic: Add dma-contiguous.h
> arm64: use generic dma-contiguous.h
> x86: use generic dma-contiguous.h
> mips: dma: Add cma support
>
> arch/arm64/include/asm/Kbuild | 1 +
> arch/arm64/include/asm/dma-contiguous.h | 28 -------------------------
> arch/mips/Kconfig | 1 +
> arch/mips/include/asm/Kbuild | 1 +
> arch/mips/kernel/setup.c | 9 ++++++++
> arch/mips/mm/dma-default.c | 37 ++++++++++++++++++++++-----------
> arch/x86/include/asm/Kbuild | 1 +
> arch/x86/include/asm/dma-contiguous.h | 12 -----------
> include/asm-generic/dma-contiguous.h | 9 ++++++++
> 9 files changed, 47 insertions(+), 52 deletions(-)
> delete mode 100644 arch/arm64/include/asm/dma-contiguous.h
> delete mode 100644 arch/x86/include/asm/dma-contiguous.h
> create mode 100644 include/asm-generic/dma-contiguous.h
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v3 3/3] arm64: Use include/asm-generic/io.h
From: Thierry Reding @ 2014-07-17 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717120441.GI18203@arm.com>
On Thu, Jul 17, 2014 at 01:04:41PM +0100, Catalin Marinas wrote:
> On Wed, Jul 16, 2014 at 12:01:24PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Include the generic I/O header file so that duplicate implementations
> > can be removed. This will also help to establish consistency across more
> > architectures regarding which accessors they support.
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Changes in v3:
> > - add io{read,write}{16,32}be() to match what 32-bit ARM does
>
> It looks fine. Thanks.
Great. Russell hasn't commented on this yet, anyone know how to get his
attention?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/903ffc89/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox