>On 29/01/15 15:40, Bryan O'Donoghue wrote:
>>> It would be nice to have two variants (1) index based & (2) address
>>> based.
>>
>> Understood. The direction from Ingo was to have address based external
>> interface imr_del_range() and support an index based internal
>> imr_clear() - internally.
On 29/01/15 15:40, Bryan O'Donoghue wrote:
It would be nice to have two variants (1) index based & (2) address
based.
Understood. The direction from Ingo was to have address based external
interface imr_del_range() and support an index based internal
imr_clear() - internally.
So - in order to
ernel@vger.kernel.org; Andy Shevchenko; Ingo
Molnar
Subject: Re: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
On 29/01/15 13:47, Ong, Boon Leong wrote:
Bryan,
Once you have the next revision ready, I would like to test it on my end across
both Galileo Gen v1 & v2.
Cheers,
; Andy Shevchenko; Ingo
>Molnar
>Subject: Re: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
>
>On 29/01/15 13:47, Ong, Boon Leong wrote:
>> Bryan,
>>
>> Once you have the next revision ready, I would like to test it on my end
>> across
>both Ga
On 29/01/15 13:47, Ong, Boon Leong wrote:
Bryan,
Once you have the next revision ready, I would like to test it on my end across
both Galileo Gen v1 & v2.
Cheers,
BL
Andy/BL - thanks for taking the time to test.
I may end up dropping the imr_del_range() tests based on index as a
result of
rnel@vger.kernel.org; Andy Shevchenko; Ingo
>Molnar
>Subject: RE: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
>
>Bryan,
>
>Once you have the next revision ready, I would like to test it on my end across
>both Galileo Gen v1 & v2.
>
>Cheers,
>BL
>
evchenko; Ingo Molnar
>Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x...@kernel.org;
>dvh...@infradead.org; Ong, Boon Leong; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
>
>On 29/01/15 10:08, Andy Shevchenko wrote:
>
On 29/01/15 07:44, Ingo Molnar wrote:
Hi Ingo.
I'll transmit those changes in with the following exception
+ ret = imr_write(idev, reg, &imr, false);
So 'ret' here gets mixed with other potential failure modes.
If imr_write() fails here then that's a highly anomalous internal
failure
On 29/01/15 10:08, Andy Shevchenko wrote:
On Thu, Jan 29, 2015 at 9:44 AM, Ingo Molnar wrote:
* Bryan O'Donoghue wrote:
[]
In any case, I don't see any major problems with this code, so if
it's fixed it could go into v3.20.
Brian, it would be really nice to have it in 3.20 since we have
On Thu, Jan 29, 2015 at 9:44 AM, Ingo Molnar wrote:
> * Bryan O'Donoghue wrote:
[]
> In any case, I don't see any major problems with this code, so if
> it's fixed it could go into v3.20.
Brian, it would be really nice to have it in 3.20 since we have
several drivers already in upstream or be
Bryan, a minor fix on the config below...
>diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index
>61bd2ad..fcf5701 100644
>--- a/arch/x86/Kconfig.debug
>+++ b/arch/x86/Kconfig.debug
>@@ -313,6 +313,18 @@ config DEBUG_NMI_SELFTEST
>
> If unsure, say N.
>
>+config DEBUG_IMR_SEL
* Bryan O'Donoghue wrote:
> Intel's Quark X1000 SoC contains a set of registers called
> Isolated Memory Regions. IMRs are accessed over the IOSF
> mailbox interface. IMRs are areas carved out of memory that
> define read/write access rights to the various system agents
> within the Quark sy
On Wed, Jan 28, 2015 at 06:36:25PM +, Bryan O'Donoghue wrote:
> Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
> Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
> carved out of memory that define read/write access rights to the various
> sy
Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
carved out of memory that define read/write access rights to the various
system agents within the Quark system. For a given agent in the system it is
On Thu, Jan 08, 2015 at 03:11:35PM +, Bryan O'Donoghue wrote:
>
> >Suggest to split the imr_del() into 2 functions:-
> >(1) by address + size
> >(2) by IMR index
> >At current implementation, it does not support (2) only because it fails at
> >imr_check_range().
>
> Hi Boon Leong.
>
> I'll h
Suggest to split the imr_del() into 2 functions:-
(1) by address + size
(2) by IMR index
At current implementation, it does not support (2) only because it fails at
imr_check_range().
Hi Boon Leong.
I'll have a think about that :)
Just on imr_del() though, it does support removal by way of i
>On 07/01/15 23:45, Ong, Boon Leong wrote:
>>> Since BIOS and grub code both use 0x as the 'off' address I
>>> think it makes sense for the kernel to continue to use that address.
>>
>> Just add on top of what Daren mentioned in another mail, based on the
>> Quark document, the base address
>>> +/**
>>> + * imr_del_range - Delete an Isolated Memory Region
>>> + * @reg: IMR index to remove
>>> + * @base: Physical base address of region aligned to 4k
>>> + * @size: Physical size of region in bytes
>>> + * @return:-EINVAL on invalid range or out or range id
>>> + * -ENODE
On 08/01/15 00:04, Ong, Boon Leong wrote:
Hi Boon Leong - skipping the simple stuff.
+/**
+ * imr_del_range - Delete an Isolated Memory Region
+ * @reg: IMR index to remove
+ * @base: Physical base address of region aligned to 4k
+ * @size: Physical size of region in bytes
+ * @return:-EINV
On 07/01/15 23:45, Ong, Boon Leong wrote:
Since BIOS and grub code both use 0x as the 'off' address I think it
makes sense for the kernel to continue to use that address.
Just add on top of what Daren mentioned in another mail, based on the Quark
document,
the base address can start fr
infradead.org; platform-driver-...@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Cc: Bryan O'Donoghue
>Subject: [PATCH 1/2] x86: Add Isolated Memory Regions for Quark X1000
>
Suggest to add a statement on 3 different types of IMR: General IMR,
Host Memory I/O Boundary IMR & Sys
>>> +/**
>>> + * imr_enabled
>>> + * Determines if an IMR is enabled based on address range
>>> + *
>>> + * @imr: Pointer to IMR descriptor
>>> + * @return true if IMR enabled false if disabled
>>> + */
>>> +static int imr_enabled(struct imr *imr) {
>>> + return (imr_to_phys(imr->addr_lo) && im
On Tue, Jan 06, 2015 at 01:43:23PM +, Bryan O'Donoghue wrote:
> On 06/01/15 07:36, Darren Hart wrote:
>
> >>Signed-off-by: Bryan O'Donoghue
> >
> >Since you have Intel (C) below and then your own, are you the sole author?
>
> Yes, for the platform code.
>
> Platform code tears-down IMRs and
On 06/01/15 07:36, Darren Hart wrote:
Signed-off-by: Bryan O'Donoghue
Since you have Intel (C) below and then your own, are you the sole author?
Yes, for the platform code.
Platform code tears-down IMRs and sets-up up a new one around the
kernel. Quark BSP does a similar thing in a differ
On Mon, Dec 29, 2014 at 05:23:02PM +, Bryan O'Donoghue wrote:
> Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
> Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
> carved out of memory that define read/write access rights to the various
> sy
On 31/12/14 15:05, Andy Shevchenko wrote:
>> +int imr_del(int reg, unsigned long base, unsigned long size);
>
> Same comments as for add_range.
> Could it be imr_remove_range() ?
Can be. You've actually caught me out there, function name is "imr_del"
function description says imr_del_range(). Am
On Mon, Dec 29, 2014 at 7:23 PM, Bryan O'Donoghue
wrote:
> Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
> Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
> carved out of memory that define read/write access rights to the various
> system age
Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
carved out of memory that define read/write access rights to the various
system agents within the Quark system. For a given agent in the system it is
28 matches
Mail list logo
