* question about irq_enter()/irq_exit() calling policy
From: Russell King - ARM Linux @ 2016-11-30 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22d0d991-bbe2-ce10-5202-3cdf97a9ecf2@ti.com>
On Tue, Nov 29, 2016 at 05:47:12PM -0600, Grygorii Strashko wrote:
> 2) Should these function be called for each processed irq?
>
>
> HW IRQ:
> switch (IRQ mode)
> ...
> while (irq = get_pending_irq()) {
> ...
> irq_enter()
> handle(irq) - execute hw_irq_hadler
> irq_exit()
> }
> ...
> switch
We tend to do (2) as a general rule, which isn't much different from what
other architectures do - even if they have a method to directly enter
through vectors (eg, x86) the effect of two pending interrupts is that one
will run after each other, and there will be an intervening exit -> entry.
In the case of ARM CPUs, if the interrupt signal is active, you vector
back to the interrupt handler as soon as you exit back to the parent
context without executing any parent context instructions.
So, we have the choice of going through all the IRQ entry code, processing
one interrupt, and returning only to then re-vector back through the IRQ
entry code, or we can process all the pending IRQs that we can see at that
time.
The former method wastes all the CPU cycles getting from the parent context
to the IRQ context for each and every interrupt.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Felipe Balbi @ 2016-11-30 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-7-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/cdce8504/attachment.sig>
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Will Deacon @ 2016-11-30 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c9012fd-070b-6218-48e7-69b37f2559dd@redhat.com>
On Wed, Nov 30, 2016 at 10:49:33AM +0100, Auger Eric wrote:
> On 15/11/2016 14:09, Eric Auger wrote:
> > Following LPC discussions, we now report reserved regions through
> > iommu-group sysfs reserved_regions attribute file.
> >
> > Reserved regions are populated through the IOMMU get_resv_region callback
> > (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
> > arm-smmu.
> >
> > The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
> > IOMMU_RESV_NOMAP reserved region.
> >
> > arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
> > 1MB large) and the PCI host bridge windows.
> >
> > The series integrates a not officially posted patch from Robin:
> > "iommu/dma: Allow MSI-only cookies".
> >
> > This series currently does not address IRQ safety assessment.
>
> I will respin this series taking into account Joerg's comment. Does
> anyone have additional comments or want to put forward some conceptual
> issues with the current direction and with this implementation?
>
> As for the IRQ safety assessment, in a first step I would propose to
> remove the IOMMU_CAP_INTR_REMAP from arm-smmus and consider the
> assignment as unsafe. Any objection?
Well, yeah, because it's perfectly safe with GICv3.
Will
^ permalink raw reply
* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-30 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129211716.GA15594@katana>
Hello,
Le 29/11/2016 ? 22:17, Wolfram Sang a ?crit :
>> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
>> + i2c->fm_mask = ICR_BUSMODE_FM;
>> + i2c->hs_mask = ICR_BUSMODE_HS;
>> + } else {
>> + i2c->fm_mask = ICR_FM;
>> + i2c->hs_mask = ICR_HS;
>> + }
>>
>> *i2c_types = (enum pxa_i2c_types)(of_id->data);
>>
>> @@ -1181,6 +1194,13 @@ static int i2c_pxa_probe_pdata(struct platform_device *pdev,
>> i2c->master_code = 0xe;
>> i2c->rate = plat->rate;
>> }
>> + if (!strcmp(id->name, "armada-3700-i2c")) {
>> + i2c->fm_mask = ICR_BUSMODE_FM;
>> + i2c->hs_mask = ICR_BUSMODE_HS;
>> + } else {
>> + i2c->fm_mask = ICR_FM;
>> + i2c->hs_mask = ICR_HS;
>> + }
>
> Okay, having the same code twice is not nice as well.
>
> Sorry for missing this in the first review and going a step back, but I
> think now the best solution is to have again a REGS_A3700 struct, but we
> should extend it with new entries for the shifted bits. Then in the init
> code, you can do something like:
>
> i2c->fm_mask = pxa_reg_layout[i2c_type].fm_mask ?: ICR_FM;
>
> Makes sense?
Mhhhh... makes sense yes, it is simpler and would remove the duplicated
code, yes (no no need to modify probe_dt and probe_pdata in this case).
What do you prefer everything in one commit or two seperated commit ?
(one including the new fields for fm_mask and another one to add support
for a3700-i2c).
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Maninder Singh @ 2016-11-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
variable name can have Non NULL terminated string after cropping
which may result strcat to fail, and cropping is not
required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
Issue caught with static analysis tool:
"Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 759e1d4..8adf272 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -742,12 +742,15 @@ static int _init_main_clk(struct omap_hwmod *oh)
char name[MOD_CLK_MAX_NAME_LEN];
struct clk *clk;
- /* +7 magic comes from '_mod_ck' suffix */
- if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
+ /* +8 magic comes from strlen("_mod_ck") added as suffix */
+ if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
pr_warn("%s: warning: cropping name for %s\n", __func__,
oh->name);
+ strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 8);
+ name[MOD_CLK_MAX_NAME_LEN - 8] = '\0';
+ } else
+ strcpy(name, oh->name);
- strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
strcat(name, "_mod_ck");
clk = clk_get(NULL, name);
--
1.9.1
^ permalink raw reply related
* [PATCH 08/12] usb: phy: msm: Replace the extcon API
From: Felipe Balbi @ 2016-11-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-9-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/ebaada64/attachment.sig>
^ permalink raw reply
* [PATCH 09/12] usb: phy: omap-otg: Replace the extcon API
From: Felipe Balbi @ 2016-11-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-10-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/9097169c/attachment-0001.sig>
^ permalink raw reply
* [PATCH 10/12] usb: phy: qcom-8x16-usb: Replace the extcon API
From: Felipe Balbi @ 2016-11-30 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-11-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/5f349ded/attachment.sig>
^ permalink raw reply
* [PATCH 11/12] usb: phy: tahvo: Replace the deprecated extcon API
From: Felipe Balbi @ 2016-11-30 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-12-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/1ab45db2/attachment.sig>
^ permalink raw reply
* [PATCH 12/12] usb: renesas_usbhs: Replace the deprecated extcon API
From: Felipe Balbi @ 2016-11-30 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-13-git-send-email-cw00.choi@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> This patch replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/85910a19/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Lorenzo Pieralisi @ 2016-11-30 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480452310-29286-1-git-send-email-jeremy.linton@arm.com>
On Tue, Nov 29, 2016 at 02:45:10PM -0600, Jeremy Linton wrote:
> The PCIe root complex on Juno translates the MMIO mapped
> at 0x5f800000 to the PIO address range starting at 0
> (which is common because PIO addresses are generally < 64k).
> Correct the DT to reflect this.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index 334271a..7d3a2ac 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -393,7 +393,7 @@
> #address-cells = <3>;
> #size-cells = <2>;
> dma-coherent;
> - ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000>,
> + ranges = <0x01000000 0x00 0x00000000 0x00 0x5f800000 0x0 0x00800000>,
> <0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000>,
> <0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> #interrupt-cells = <1>;
> --
> 2.5.5
>
^ permalink raw reply
* [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-11-30 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3478036.d2UQM8n6lv@avalon>
On Wed, 30 Nov 2016 11:52:25 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Jean-Fran?ois,
>
> On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
> > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
> > >> Well, I don't see what this connector can be.
> > >> May you give me a DT example?
> > >
> > > Sure.
> > >
> > > arch/arm/boot/dts/r8a7791-koelsch.dts
> > >
> > > /* HDMI encoder */
[snip]
> > > /* HDMI connector */
> > >
> > > hdmi-out {
> > > compatible = "hdmi-connector";
> > > type = "a";
> > >
> > > port {
> > > hdmi_con: endpoint {
> > > remote-endpoint = <&adv7511_out>;
> > > };
> > > };
> > > };
[snip]
> > - what does the software do with the connector type?
>
> That's up to the software to decide, the DT bindings should describe the
> hardware in the most accurate and usable way for the OS as possible. One of my
> longer term goals is to add connector drivers to handle DDC and HPD when
> they're not handled by the encoder (they are in the above example).
>
> If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD
> to a GPIO, we would have
>
> hdmi-out {
> compatible = "hdmi-connector";
> type = "a";
> /* I2C bus and GPIO references are made up for the example */
> ddc-i2c-bus = <&i2c4>;
> hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>
> port {
> hdmi_con: endpoint {
> remote-endpoint = <&adv7511_out>;
> };
> };
> };
>
> and both HPD and EDID reading should be handled by the connector driver.
[snip]
Hi Laurent,
OK. I understand. This connector complexity should be added in all DTs,
and the same code would be used.
Actually, for component binding, I use drm_of_component_probe():
- from the DRM master, loop on the "ports" phandle array and bind the
CRTCs,
- for each CRTC, loop on the first remote port level and bind the
encoders/connectors
Now, this should be:
- from the DRM master, loop on the first remote ports level and bind
the CRTCs,
- for each CRTC, loop on the second remote port level and bind the
encoders (and bridges?),
- for each encoder, loop on the third remote port level and bind the
connectors.
Then, it would be nice to have a generic function for doing this job.
Otherwise, from your description:
> hdmi-out {
> compatible = "hdmi-connector";
> type = "a";
> /* I2C bus and GPIO references are made up for the example */
> ddc-i2c-bus = <&i2c4>;
> hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
the "hdmi-connector" is a big piece of software. It must handle a lot
of more and more exotic connectors.
So, I hope that you have written a "simple-hdmi-connector" which does
nothing but setting the connector type.
Where is it?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v10 11/13] drm/mediatek: add dsi rxtx control
From: CK Hu @ 2016-11-30 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-12-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> add non-continuous clock mode and EOT packet control for dsi
>
I think commit title should be 'drm/mediatek: add non-continuous clock
mode and EOT packet control for dsi', and commit message should describe
more information about this modification. For example, what is the
difference between with and without this patch. Does it fix any problem?
Regards,
CK
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 01df829..ded4202 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -399,6 +399,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
> break;
> }
>
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
> +
> writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
> }
>
^ permalink raw reply
* [PATCH 1/2] arm64: Correcting format specifier for printin 64 bit addresses
From: Will Deacon @ 2016-11-30 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480493036-47334-1-git-send-email-maninder1.s@samsung.com>
On Wed, Nov 30, 2016 at 01:33:56PM +0530, Maninder Singh wrote:
> This patch corrects format specifier for printing 64 bit addresses.
>
> Before Patch
> ============
> [ 68.251603] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 68.251673] pgd = ffffffc013950000
> [ 68.251782] [00000000] *pgd=0000000093e19003, *pud=0000000093e19003, *pmd=0000000000000000
>
> After patch
> ===========
> [ 8.565030] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 8.565389] pgd = ffffffc013872000
> [ 8.565553] [0000000000000000] *pgd=0000000093874003, *pud=0000000093874003, *pmd=0000000000000000
>
> and same for user space fault.
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> ---
> arch/arm64/mm/fault.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
There are a bunch of these you haven't caught:
arch/arm64/kernel/signal.c: pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
arch/arm64/kernel/signal32.c: pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
arch/arm64/kernel/signal32.c: pr_info_ratelimited("%s[%d]: bad frame in %s: pc=%08llx sp=%08llx\n",
arch/arm64/kvm/sys_regs.c: kvm_err("Unsupported guest CP%d access at: %08lx\n",
arch/arm64/kvm/trace.h: TP_printk("guest executed wf%c at: 0x%08lx",
arch/arm64/kvm/trace.h: TP_printk("HVC at 0x%08lx (r0: 0x%08lx, imm: 0x%lx)",
arch/arm64/kvm/trace.h: TP_printk("%s %s reg %d (0x%08llx)", __entry->fn, __entry->is_write?"write to":"read from", __entry->reg, __entry->write_value)
arch/arm64/mm/fault.c: pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
arch/arm64/mm/fault.c: pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
arch/arm64/mm/fault.c: pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
arch/arm64/mm/mmu.c: pr_warn("fix_to_virt(FIX_BTMAP_BEGIN): %08lx\n",
arch/arm64/mm/mmu.c: pr_warn("fix_to_virt(FIX_BTMAP_END): %08lx\n",
so it would probably make sense to fix these to be consistent.
Will
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Sebastian Frias @ 2016-11-30 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFd313zQHmFQ61Y4UEvQAvhhVeNFe=nNyjXUKfYXiTKnvm9VWQ@mail.gmail.com>
On 29/11/16 08:29, Rameshwar Sahu wrote:
> Hi Mason,
>
> Nowhere in the documentation do they specify an "IP version".
> Some documents do provide a revision number, but that's just
> a *documentation* revision number, e.g.
>
> changes in version 3.6 : fix typos
> changes in version 9.1a : update company logo
>
> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
> "arasan,sdhci-4.9a". These are documentation revisions.
> In my opinion, that information is mostly worthless.
>
For the record, the important information conveyed by Rameshwar's
email is the following:
Arasan SD/SDIO/eMMC IP has a register which tells about the SD
specification version and Vendor version number
Reg Name: Host controller version register (offset 0FEh)
bit [15:8] is for vendor version number,
But, I have seen that Arasaan vendor version number is same as
document revision number.
(At first I had ignored the email because it repeated Mason's email
without quoting, but then I realised it contained some information)
>
> On Mon, Nov 28, 2016 at 10:22 PM, Mason <slash.tmp@free.fr> wrote:
>> On 28/11/2016 17:15, Arnd Bergmann wrote:
>>
>>> On Monday, November 28, 2016 4:44:39 PM CET Mason wrote:
>>>
>>>> Hello,
>>>>
>>>> @Shawn Lin, could you take a look below and tell me exactly
>>>> which IP core(s) Rockchip is using in its SoCs?
>>>>
>>>> Based on the feedback I received, here is an updated list of
>>>> compatible strings and controller versions dealt with by the
>>>> drivers/mmc/host/sdhci-of-arasan.c code.
>>>>
>>>>
>>>> Xilinx Zynq:
>>>> "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller"
>>>> "arasan,sdhci-8.9a"
>>>> NB: 8.9a is the documentation revision (dated 2011-10-19)
>>>> subsequent tweaks labeled 9.0a, 9.1a, 9.2a
>>>>
>>>> Xilinx ZynqMP:
>>>> "SD3.0 / SDIO3.0 / eMMC4.51 AHB Host Controller"
>>>> "arasan,sdhci-8.9a"
>>>> NB: using the same compatible string as Zynq
>>>>
>>>> Sigma SMP87xx
>>>> "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
>>>> no compatible string yet, platform-specific init required
>>>>
>>>> APM:
>>>> "SD3.0 / SDIO3.0 / eMMC4.41 AHB Host Controller"
>>>> "arasan,sdhci-4.9a"
>>>> NB: 4.9a appears to be the documentation revision
>>>> no functional diff with "arasan,sdhci-8.9a"
>>>>
>>>> Rockchip
>>>> Exact IP unknown, waiting for Shawn's answer
>>>> "arasan,sdhci-5.1"
>>>> NB: 5.1 appears to refer to the eMMC standard supported
>>>>
>>>>
>>>> On a final note, there are many variations of the Arasan IP.
>>>> I've tracked down at least the following:
>>>>
>>>> SD_2.0_SDIO_2.0__MMC_3.31_AHB_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.41_OCP_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf
>>>> SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller.pdf
>>>> SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller.pdf
>>>>
>>>> It seems to me the compatible string should specify
>>>> the SD/SDIO version AND the eMMC version, since it
>>>> seems many combinations are allowed, e.g. eMMC 4.51
>>>> has two possible SD versions.
>>>>
>>>> What do you think?
>>>
>>> It seems wrong to have the eMMC or SD version in the compatible
>>> string. Is that the only difference between the documents you
>>> found? Normally there should be a version of IP block itself,
>>> besides the supported protocol.
>>
>> But that is exactly the problem :-)
>>
>> Nowhere in the documentation do they specify an "IP version".
>> Some documents do provide a revision number, but that's just
>> a *documentation* revision number, e.g.
>>
>> changes in version 3.6 : fix typos
>> changes in version 9.1a : update company logo
>>
>> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
>> "arasan,sdhci-4.9a". These are documentation revisions.
>> In my opinion, that information is mostly worthless.
>>
>>
>> Looking more closely at SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
>> (User Guide, which has more info than Datasheet) I see this:
>>
>> Changed Host Controller Version Register value from 16'h0002 to 16'h7501
>> Changed Host Controller Version Register value from 16'h8301 to 16'h8401
>> Changed Host Controller Version Register value from 16'h8401 to 16'h8501
>> Changed Host Controller Version Register to 16'h9502
>> Changed Host Controller Version Register to 16'h9602
>> Changed Host Controller Version Register to 16'h9902
>>
>> Host controller version register (offset 0FEh)
>>
>> Vendor Version Number 15:8
>> HwInit=0x99
>> This status is reserved for the vendor version number.
>> The HD should not use this status.
>>
>> Specification Version Number 7:0
>> HwInit=0x02
>> This status indicates the Host Controller Spec. Version.
>> The upper and lower 4-bits indicate the version.
>> Description
>> 00 - SD Host Specification version 1.0
>> 01 - SD Host Specification version 2.00
>> including only the feature of the Test Register
>> 02 - SD Host Specification Version 3.00
>> others - Reserved
>>
>> I'm not sure what this "Vendor Version Number" specifies, nor if is
>> guaranteed to be unique across controllers.
>>
>> In SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller_UserGuide.pdf,
>> they write "The Vendor Version Number is set to 0x10 (1.0)"
>>
>> I don't have a UserGuide for "arasan,sdhci-5.1".
>>
>> Regards.
>>
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Ganapatrao Kulkarni @ 2016-11-30 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d0ddb50-6e63-3fe2-55c0-ce49579905c9@redhat.com>
On Wed, Nov 30, 2016 at 3:44 PM, Auger Eric <eric.auger@redhat.com> wrote:
> Hi Ganapat,
>
> On 30/11/2016 11:04, Ganapatrao Kulkarni wrote:
>> Hi Eric,
>>
>> in you repo "https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3"
>> there is 11th patch "pci: Enable overrides for missing ACS capabilities"
>> is this patch part of some other series?
>
> Actually this is a very old patch from Alex aimed at working around lack
> of PCIe ACS support: https://lkml.org/lkml/2013/5/30/513
>
i have tried this patchset on thunderx-83xx for vfio and it works for me!
i was wondering is this patch required? i guess not.
please cc me when you respin this patchset.
thanks
Ganapat
> Thanks
>
> Eric
>>
>> thanks
>> Ganapat
>>
>> On Wed, Nov 30, 2016 at 3:19 PM, Auger Eric <eric.auger@redhat.com> wrote:
>>> Hi,
>>>
>>> On 15/11/2016 14:09, Eric Auger wrote:
>>>> Following LPC discussions, we now report reserved regions through
>>>> iommu-group sysfs reserved_regions attribute file.
>>>>
>>>> Reserved regions are populated through the IOMMU get_resv_region callback
>>>> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
>>>> arm-smmu.
>>>>
>>>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>>>> IOMMU_RESV_NOMAP reserved region.
>>>>
>>>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
>>>> 1MB large) and the PCI host bridge windows.
>>>>
>>>> The series integrates a not officially posted patch from Robin:
>>>> "iommu/dma: Allow MSI-only cookies".
>>>>
>>>> This series currently does not address IRQ safety assessment.
>>>
>>> I will respin this series taking into account Joerg's comment. Does
>>> anyone have additional comments or want to put forward some conceptual
>>> issues with the current direction and with this implementation?
>>>
>>> As for the IRQ safety assessment, in a first step I would propose to
>>> remove the IOMMU_CAP_INTR_REMAP from arm-smmus and consider the
>>> assignment as unsafe. Any objection?
>>>
>>> Thanks
>>>
>>> Eric
>>>
>>>
>>>> Best Regards
>>>>
>>>> Eric
>>>>
>>>> Git: complete series available at
>>>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>>>
>>>> History:
>>>> RFC v2 -> v3:
>>>> - switch to an iommu-group sysfs API
>>>> - use new dummy allocator provided by Robin
>>>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>>>> the reserved regions
>>>> - at the moment ARM MSI base address/size is left unchanged compared
>>>> to v2
>>>> - we currently report reserved regions and not usable IOVA regions as
>>>> requested by Alex
>>>>
>>>> RFC v1 -> v2:
>>>> - fix intel_add_reserved_regions
>>>> - add mutex lock/unlock in vfio_iommu_type1
>>>>
>>>>
>>>> Eric Auger (10):
>>>> iommu/dma: Allow MSI-only cookies
>>>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>>>> iommu: Add new reserved IOMMU attributes
>>>> iommu: iommu_alloc_resv_region
>>>> iommu: Do not map reserved regions
>>>> iommu: iommu_get_group_resv_regions
>>>> iommu: Implement reserved_regions iommu-group sysfs file
>>>> iommu/vt-d: Implement reserved region get/put callbacks
>>>> iommu/arm-smmu: Implement reserved region get/put callbacks
>>>> vfio/type1: Get MSI cookie
>>>>
>>>> drivers/iommu/amd_iommu.c | 20 +++---
>>>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
>>>> drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++++-------
>>>> drivers/iommu/intel-iommu.c | 50 ++++++++++----
>>>> drivers/iommu/iommu.c | 141 ++++++++++++++++++++++++++++++++++++----
>>>> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
>>>> include/linux/dma-iommu.h | 7 ++
>>>> include/linux/iommu.h | 49 ++++++++++----
>>>> 8 files changed, 391 insertions(+), 70 deletions(-)
>>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] watchdog: meson: Remove unneeded platform MODULE_ALIAS
From: Guenter Roeck @ 2016-11-30 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7149198-b513-4022-5fbc-10067d420191@osg.samsung.com>
On 11/29/2016 06:57 AM, Javier Martinez Canillas wrote:
> Hello Wim,
>
> On 10/20/2016 07:28 PM, Guenter Roeck wrote:
>> On Wed, Oct 19, 2016 at 04:49:42PM -0300, Javier Martinez Canillas wrote:
>>> The Amlogic Meson is a DT-only platform, which means the devices are
>>> registered via OF and not using the legacy platform devices support.
>>>
>>> So there's no need to have a MODULE_ALIAS("platform:meson-gxbb-wdt")
>>> since the reported uevent MODALIAS to user-space will be the OF one.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>
>
> Any comments about this patch? There are other two similar fixes for
> watchdog drivers that were also reviewed by Guenter but never picked:
>
> https://lkml.org/lkml/2016/10/14/412
> https://lkml.org/lkml/2016/10/14/413
>
> Best regards,
>
The patches are all in my watchdog-next branch, so Wim will hopefully
pick them up for the next release.
Guenter
^ permalink raw reply
* [PATCH 5/9] arm64: cpufeature: Define helpers for sys_reg id
From: Will Deacon @ 2016-11-30 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479994809-9081-6-git-send-email-suzuki.poulose@arm.com>
On Thu, Nov 24, 2016 at 01:40:05PM +0000, Suzuki K Poulose wrote:
> Define helper macros to extract op0, op1, CRn, CRm & op2
> for a given sys_reg id.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 6c80b36..488b939 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -34,8 +34,27 @@
> * [11-8] : CRm
> * [7-5] : Op2
> */
> +#define Op0_shift 19
> +#define Op0_mask 0x3
> +#define Op1_shift 16
> +#define Op1_mask 0x7
> +#define CRn_shift 12
> +#define CRn_mask 0xf
> +#define CRm_shift 8
> +#define CRm_mask 0xf
> +#define Op2_shift 5
> +#define Op2_mask 0x7
> +
> #define sys_reg(op0, op1, crn, crm, op2) \
> - ((((op0)&3)<<19)|((op1)<<16)|((crn)<<12)|((crm)<<8)|((op2)<<5))
> + ((((op0) & Op0_mask) << Op0_shift) | \
> + ((op1) << Op1_shift) | ((crn) << CRn_shift) | \
> + ((crm) << CRm_shift) | ((op2) << Op2_shift))
You're preserving the current behaviour here, but why do we care so much
about masking op0 but then not bother masking any of the other fields?
Will
^ permalink raw reply
* [PATCH v10 09/13] drm/mediatek: add mipi_tx data rate check
From: CK Hu @ 2016-11-30 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-10-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> modify data rate limitation (>lGbps/lane) for mipitx
>
I think MT2701 DRM can work correctly without this patch.
Why do you put this patch in MT2701 series?
Maybe you can send this patch independently.
Regards,
CK
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fd84914..1ef00ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>
> dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>
> - if (mipi_tx->data_rate >= 500000000) {
> + if (mipi_tx->data_rate > 1250000000) {
> + return -EINVAL;
> + } else if (mipi_tx->data_rate >= 500000000) {
> txdiv = 1;
> txdiv0 = 0;
> txdiv1 = 0;
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Szabolcs Nagy @ 2016-11-30 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a35d1ae-73df-03a5-c9d6-1a52754acf25@redhat.com>
On 30/11/16 10:08, Florian Weimer wrote:
> On 11/25/2016 08:38 PM, Dave Martin wrote:
>> The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which
>> adds extra SIMD functionality and supports much larger vectors.
>>
>> This series implements core Linux support for SVE.
>>
>> Recipents not copied on the whole series can find the rest of the
>> patches in the linux-arm-kernel archives [2].
>>
>>
>> The first 5 patches "arm64: signal: ..." factor out the allocation and
>> placement of state information in the signal frame. The first three
>> are prerequisites for the SVE support patches.
>>
>> Patches 04-05 implement expansion of the signal frame, and may remain
>> controversial due to ABI break issues:
>>
>> * Discussion is needed on how userspace should detect/negotiate signal
>> frame size in order for this expansion mechanism to be workable.
>
> I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to
> disable really wide vector registers in case this causes problems with old binaries.
>
if the kernel does not increase the size and libc
does not add size checks then old binaries would
work with new libc just fine..
but that's non-conforming, posix requires the check.
if the kernel increases the size then it has to be
changed in bionic and musl as well and old binaries
may break.
> A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to
> its complexity.
>
>> The remaining patches implement initial SVE support for Linux, with the
>> following limitations:
>>
>> * No KVM/virtualisation support for guests.
>>
>> * No independent SVE vector length configuration per thread. This is
>> planned, but will follow as a separate add-on series.
>
> Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable
> functions/executors quite challenging.
>
i'd assume it's undefined to context switch to a different
thread or to resume a function on a different thread
(because the implementation can cache thread local state
on the stack: e.g. errno pointer).. of course this does
not stop ppl from doing it, but the practice is questionable.
> Can you detail your plans in this area?
>
> Thanks,
> Florian
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Siddhesh Poyarekar @ 2016-11-30 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479994809-9081-10-git-send-email-suzuki.poulose@arm.com>
On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
> + d) CPU Identification :
> + MIDR_EL1 is exposed to help identify the processor. On a
> + heterogeneous system, this could be racy (just like getcpu()). The
> + process could be migrated to another CPU by the time it uses the
> + register value, unless the CPU affinity is set. Hence, there is no
> + guarantee that the value reflects the processor that it is
> + currently executing on. The REVIDR is not exposed due to this
> + constraint, as REVIDR makes sense only in conjunction with the
> + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
> + at:
> +
> + /sys/devices/system/cpu/cpu$ID/regs/identification/
> + \- midr
> + \- revidr
> +
This doesn't seem to be implemented in this patchset.
Siddhesh
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Sricharan @ 2016-11-30 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e91ce72-9d37-f4be-9224-856a1a4c3e1d@samsung.com>
Hi,
>Hi Sricharan and Robin,
>
>
>On 2016-11-30 01:22, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: massive PCI hacks]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/base/dma-mapping.c | 4 ++--
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 5 +++--
>> drivers/of/device.c | 9 +++++++--
>> drivers/pci/probe.c | 6 ++++--
>> include/linux/of_device.h | 9 ++++++---
>> include/linux/pci.h | 4 ++--
>> 7 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> index b2a5629..576fdfb 100644
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
>> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
>> int dma_configure(struct device *dev)
>> {
>> if (dev_is_pci(dev))
>> - pci_dma_configure(dev);
>> + return pci_dma_configure(dev);
>> else if (dev->of_node)
>> - of_dma_configure(dev, dev->of_node);
>> + return of_dma_configure(dev, dev->of_node);
>> return 0;
>> }
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..d2a7a46 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> base_pfn = max_t(unsigned long, 1, base >> order);
>> end_pfn = (base + size - 1) >> order;
>>
>> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n", base, size, domain->geometry.aperture_start, domain-
>>geometry.aperture_end,
>
>This causes a NULL pointer dereference if caller passes NULL device pointer.
>There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
>Trivial to fix as it looks like a leftover from developement or
>debugging stage.
>
My bad, i should have removed it before posting. Noticed this, but missed to remove it.
Will do so.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v4 00/10] IOMMU probe deferral support
From: Sricharan @ 2016-11-30 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90b1ad92-f7e6-b512-0676-90b96af10710@samsung.com>
Hi Marek,
>
>On 2016-11-30 01:22, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> | |
>> pci_bus_add_device (device_add/driver_register)
>> | |
>> device_attach device_initial_probe
>> | |
>> __device_attach_driver __device_attach_driver
>> |
>> driver_probe_device
>> |
>> really_probe
>> |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> Tested with platform and pci devices for probe deferral
>> and reprobe on arm64 based platform. Added the patches [9,10],
>> drivers: acpi: Configure acpi devices dma operation at probe time
>> drivers: acpi: Handle IOMMU lookup failure with deferred probing or error
>> for doing the dma ops configuration at probe time for acpi based platform
>> as well. Did not have a acpi based platform to test the changes and with
>> my still catching up knowledge on acpi/enumeration those two patches needs
>> to be reviewed/tested more.
>
>I've checked this patchset on my development boards: Odroid U3
>(ARM/Exynos4412),
>XU3 (ARM/Exynos5422) and TM2 (ARM64/Exynos5433) and my queued patches
>for Exynos
>IOMMU driver [1]. Besides the issue with an excessive dev_info, which
>causes NULL
>pointer dereference (reported in reply to patch #6), it works fine on
>all those
>platforms! Please add (again) my:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>[1] https://www.spinics.net/lists/linux-samsung-soc/msg56354.html
>
>> Previous post of this series [5].
Thanks for the testing every time.
Regards,
Sricharan
>>
>> [V4]
>> * Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Added the patches for moving the dma ops configuration of
>> acpi based devices to probe time as well.
>> [V3]
>> * Removed the patch to split dma_masks/dma_ops configuration
>> separately based on review comments that both masks and ops are
>> required only during the device probe time.
>>
>> * Reworked the series based on Generic DT bindings series.
>>
>> * Added call to iommu's remove_device in the cleanup path for arm and
>> arm64.
>>
>> * Removed the notifier trick in arm64 to handle early device
>> registration.
>>
>> * Added reset of dma_ops in cleanup path for arm based on comments.
>>
>> * Fixed the pci_iommu_configure path and tested with PCI device as
>> well.
>>
>> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>> last post.
>>
>> * Fixed few other cosmetic comments.
>>
>> [V2]
>> * Updated the Initial post to call dma_configure/deconfigure from
>> generic code
>>
>> * Added iommu add_device callback from of_iommu_configure path
>>
>> [V1]
>> * Initial post from Laurent Pinchart [1]
>>
>> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
>> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
>> [3] https://lkml.org/lkml/2016/11/21/141
>> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>> [5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460832.html
>>
>> Laurent Pinchart (3):
>> of: dma: Move range size workaround to of_dma_get_range()
>> of: dma: Make of_dma_deconfigure() public
>> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>>
>> Robin Murphy (3):
>> iommu/of: Refactor of_iommu_configure() for error handling
>> iommu/of: Prepare for deferred IOMMU configuration
>> iommu/arm-smmu: Clean up early-probing workarounds
>>
>> Sricharan R (4):
>> drivers: platform: Configure dma operations at probe time
>> arm64: dma-mapping: Remove the notifier trick to handle early setting
>> of dma_ops
>> drivers: acpi: Configure acpi devices dma operation at probe time
>> drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>> error
>>
>> arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>> drivers/acpi/arm64/iort.c | 17 +++++-
>> drivers/acpi/glue.c | 6 --
>> drivers/acpi/scan.c | 7 ++-
>> drivers/base/dd.c | 10 ++++
>> drivers/base/dma-mapping.c | 32 +++++++++++
>> drivers/iommu/arm-smmu-v3.c | 35 +-----------
>> drivers/iommu/arm-smmu.c | 58 +++----------------
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 114 +++++++++++++++++++++++++++-----------
>> drivers/of/address.c | 20 ++++++-
>> drivers/of/device.c | 36 ++++++------
>> drivers/of/platform.c | 10 +---
>> drivers/pci/probe.c | 17 +++---
>> include/acpi/acpi_bus.h | 2 +-
>> include/linux/acpi.h | 7 ++-
>> include/linux/dma-mapping.h | 3 +
>> include/linux/of_device.h | 10 +++-
>> include/linux/pci.h | 5 ++
>> 19 files changed, 238 insertions(+), 284 deletions(-)
>>
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Suzuki K Poulose @ 2016-11-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2f9a241-8453-0b2c-25db-e603b89acf46@reserved-bit.com>
On 30/11/16 11:14, Siddhesh Poyarekar wrote:
> On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
>> + d) CPU Identification :
>> + MIDR_EL1 is exposed to help identify the processor. On a
>> + heterogeneous system, this could be racy (just like getcpu()). The
>> + process could be migrated to another CPU by the time it uses the
>> + register value, unless the CPU affinity is set. Hence, there is no
>> + guarantee that the value reflects the processor that it is
>> + currently executing on. The REVIDR is not exposed due to this
>> + constraint, as REVIDR makes sense only in conjunction with the
>> + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
>> + at:
>> +
>> + /sys/devices/system/cpu/cpu$ID/regs/identification/
>> + \- midr
>> + \- revidr
>> +
>
> This doesn't seem to be implemented in this patchset.
This is already available upstream.
Thanks
Suzuki
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Catalin Marinas @ 2016-11-30 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2f9a241-8453-0b2c-25db-e603b89acf46@reserved-bit.com>
On Wed, Nov 30, 2016 at 04:44:52PM +0530, Siddhesh Poyarekar wrote:
> On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
> > + d) CPU Identification :
> > + MIDR_EL1 is exposed to help identify the processor. On a
> > + heterogeneous system, this could be racy (just like getcpu()). The
> > + process could be migrated to another CPU by the time it uses the
> > + register value, unless the CPU affinity is set. Hence, there is no
> > + guarantee that the value reflects the processor that it is
> > + currently executing on. The REVIDR is not exposed due to this
> > + constraint, as REVIDR makes sense only in conjunction with the
> > + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
> > + at:
> > +
> > + /sys/devices/system/cpu/cpu$ID/regs/identification/
> > + \- midr
> > + \- revidr
> > +
>
> This doesn't seem to be implemented in this patchset.
No. However, we merged the functionality above already and forgot about
the documentation part, so we just clarify it now.
--
Catalin
^ 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