Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1314821
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH v2] Add IPI entry for CPU UP |
| Date | 2016-01-22 09:10 +0100 |
| Message-ID | <qTEX9-1ic-25@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <qQ3AK-7rn-27@gated-at.bofh.it> <qQ5Me-nk-15@gated-at.bofh.it> <qTj6i-2ML-3@gated-at.bofh.it> <qTl87-45V-37@gated-at.bofh.it> <qTzkJ-5CO-1@gated-at.bofh.it> |
| Organization | ARM Ltd |
On Fri, 22 Jan 2016 10:01:24 +0800 Zhaoyang Huang <zhaoyang.huang@linaro.org> wrote: > On 21 January 2016 at 18:51, Mark Rutland <mark.rutland@arm.com> > wrote: > > On Thu, Jan 21, 2016 at 04:48:57PM +0800, Zhaoyang Huang wrote: > >> Hi Mark, > > > > Hi, > > > >> Do you have any suggestion on how to sync the GIC operation from > >> kernel and psci parallelly? Thanks! > > > > I'm not sure what you mean. > > > > What problem are you having with synchronising GIC accesses? > > > > As far as I can see, the CPU sending the IPI can simply poke the > > relevant register in the distributor without requiring any > > synchronisation. The CPU receiving the IPI is the only CPU with > > access to its CPU interface. > > > > Could you describe your problem in more detail? > > > > Thanks, > > Mark. > > > Hi Mark, > Sorry for making confusions. I mean mutex between kernel and trustzone > when accessing > GIC registers. It is possible for they two issuing an accessing to the > same register at the > same time. How should I handle such kind of race conditions? The GIC programming interface is designed to allow this kind of access without locking: - CPU interface: the CPU cannot be in secure and non-secure at the same time, so there is no race for the access. Furthermore, the fact that secure interrupts have a higher priority than non-secure ones ensure that a secure interrupt will preempt a non-secure one, making the whole thing race free. - Distributor: Writing to the GICD_SGIR register is atomic, and the GIC will ensure simultaneous access. In a nutshell, there is no need to worry about these things, because the GIC architecture has been designed from the ground up to support this. See for example this: http://git.denx.de/?p=u-boot.git;a=blob_plain;f=arch/arm/cpu/armv7/sunxi/psci_sun7i.S;hb=HEAD which uses IPIs to implement PSCI on an existing ARMv7 system. Thanks, M. -- Without deviation from the norm, progress is not possible.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH v2] Add IPI entry for CPU UP Zhaoyang Huang <zhaoyang.huang@linaro.org> - 2016-01-21 09:50 +0100
Re: [RFC PATCH v2] Add IPI entry for CPU UP Mark Rutland <mark.rutland@arm.com> - 2016-01-21 12:00 +0100
Re: [RFC PATCH v2] Add IPI entry for CPU UP Zhaoyang Huang <zhaoyang.huang@linaro.org> - 2016-01-22 03:10 +0100
Re: [RFC PATCH v2] Add IPI entry for CPU UP Marc Zyngier <marc.zyngier@arm.com> - 2016-01-22 09:10 +0100
csiph-web