* [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 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] 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 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 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 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 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 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 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 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
* [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 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
* 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] serial: mxs-auart: support CMSPAR termios cflag
From: Wolfgang Ocker @ 2016-11-30 10:16 UTC (permalink / raw)
To: linux-arm-kernel
If CMSPAR is set in the c_cflag of termios, "stick" parity is enabled.
Tested on an i.MX28 system
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
drivers/tty/serial/mxs-auart.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 770454e0dfa3..9d344f734d44 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -95,6 +95,7 @@
#define AUART_LINECTRL_BAUD_DIVFRAC_SHIFT 8
#define AUART_LINECTRL_BAUD_DIVFRAC_MASK 0x00003f00
#define AUART_LINECTRL_BAUD_DIVFRAC(v) (((v) & 0x3f) << 8)
+#define AUART_LINECTRL_SPS (1 << 7)
#define AUART_LINECTRL_WLEN_MASK 0x00000060
#define AUART_LINECTRL_WLEN(v) (((v) & 0x3) << 5)
#define AUART_LINECTRL_FEN (1 << 4)
@@ -1010,10 +1011,12 @@ static void mxs_auart_settermios(struct uart_port *u,
ctrl |= AUART_LINECTRL_WLEN(bm);
/* parity */
- if (cflag & PARENB) {
+ if (cflag & (PARENB|CMSPAR)) {
ctrl |= AUART_LINECTRL_PEN;
if ((cflag & PARODD) == 0)
ctrl |= AUART_LINECTRL_EPS;
+ if (cflag & CMSPAR)
+ ctrl |= AUART_LINECTRL_SPS;
}
u->read_status_mask = 0;
--
2.10.0
^ permalink raw reply related
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2016-11-30 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFpQJXWp5BfsxU5nkWm7hrq5wp6=b-6iYVHjBQYhmkWN_kSSzg@mail.gmail.com>
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
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 v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-11-30 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130100545.44546ed28896cdb9768f68cd@free.fr>
Hi Jean-Fran?ois,
On Wednesday 30 Nov 2016 10:05:45 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:36:50 +0100 Maxime Ripard wrote:
> > On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > > This patchset series adds HDMI video support to the Allwinner
> > > sun8i SoCs which include the display engine 2 (DE2).
> > > The driver contains the code for the A83T and H3 SoCs, and
> > > some H3 boards, but it could be used/extended for other SoCs
> > > (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> >
> > Honestly, I'm getting a bit worried by the fact that you ignore
> > reviews.
> >
> > On the important reviews that you got that are to be seen as major
> >
> > issues that block the inclusion, we have:
> > - The fact that the HDMI driver is actually just a designware IP,
> > and while you should use the driver that already exists, you just
> > duplicated all that code.
>
> The DW registers in the A83T and H3 are obfuscated, so, the code in
> bridge/DW cannot be used as it is. There should be either a translation
> table or a function to compute the register addresses.
Jernej mentioned there could be a way to restore the original Synopsys memory
map. If that works then using the dw-hdmi could be an option.
> More, it is not sure that the bridge/DW code would work with Allwinner's
> SoCs.
If it doesn't work and can't be made to work in a non-invasive way they it
should certainly not be used :-)
> It seems that they got some schematics from DesignWare, but, is it really
> the same hardware?
That's not really relevant, as long as the hardware is compatible, it doesn't
matter if it's a Synopsys IP or a custom implementation of the HDMI TX with a
compatible interface.
> Also, if some changes had to be done in the bridge code, I could not check
> if this would break or not the other SoCs.
Nothing new here, all drivers that support multiple SoCs have the same
problem. That's why we have maintainers, testers and board farms to try and
catch issues as early as possible.
> Eventually, I went the same way as omap/hdmi5: different driver.
I might try to fix that for OMAP5 at some point, we'll see.
> > - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> > graph to model the connection between the display engine and the
> > TCON. Something that Laurent also pointed out in this version.
>
> I simply use the drm function drm_of_component_probe().
> If this one is in the DRM core, why should I not use it?
> If it must not be used, it would be nice to mark it as deprecated and
> to update the code of the drivers which are using it.
I haven't used that function so I can't comment here, except for the fact that
DT bindings are not designed based on a given OS implementation. It should be
the other way around, the bindings should be designed to clearly describe the
hardware in a clean and consistent way that can be used by any host software,
and the Linux helper functions should then be developed based on those
bindings.
> > - The fact that you ignored that you needed an HDMI connector node
> > as a child of the HDMI controller. This has been reported by Rob
> > (v6) and yet again in this version by Laurent.
>
> As I don't know what is a DT 'connector', I cannot go further.
> I hope Laurent will give me clearer explanations and a real example.
Done, we can discuss this in that part of the mail thread.
> > - And finally the fact that we can't have several display engine in
> > parallel, if needs be. This has happened in the past already on
> > Allwinner SoCs, so it's definitely something we should consider in
> > the DT bindings, since we can't break them.
>
> IIRC, I proposed my driver before yours, and the DE2 is completely
> different from the other display engines.
> What you are telling is "add more code to already complex code and have
> a big driver for all SoCs in each kernels".
> I think it should be better to have small modules, each one treating
> specific hardware, and to let only the needed code in the kernel memory
> at startup time.
>
> > Until those are fixed, I cannot see how this driver can be merged,
> > unfortunately.
>
> No problem. I just wanted to help people by giving the job I did on the
> boards I have. My boards are working for almost one year, fine enough
> for I use them as daily desktop computers. I don't want to spend one
> more year for having my code in the Linux kernel: there are so much
> other exciting things to do...
And you're certainly welcome to contribute drivers to the kernel, that's
always appreciated. Of course, to ensure a reasonable level of quality and
consistency between drivers, the review process often requires changes to be
made to the code being submitted. When it comes to drivers I mostly pay
attention to DT bindings, userspace APIs and modification to common code.
Driver code itself, as long as it's reasonably clean and doesn't impede
development of other drivers or impact system security in an adverse way, is
still important but maybe slightly less so. I'll defer to Maxime to come to an
agreement on the multiple display engines in parallel problem as I'm not
familiar with it for the Allwinner platforms.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Florian Weimer @ 2016-11-30 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
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.
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.
Can you detail your plans in this area?
Thanks,
Florian
^ permalink raw reply
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Simon Horman @ 2016-11-30 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8acc79fe-393d-2b69-b7e7-e87a53d95264@cogentembedded.com>
On Tue, Nov 22, 2016 at 03:08:49PM +0300, Vladimir Barinov wrote:
> Hi Sergei,
>
> On 22.11.2016 14:40, Sergei Shtylyov wrote:
> >On 11/22/2016 2:22 PM, Vladimir Barinov wrote:
> >
> >>>>From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >>>>
> >>>>This changes SDHI0 pin names for H3ULCB board
> >>>>
> >>>>Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >>>>Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >>>>---
> >>>> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
> >>>> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>>>
> >>>>diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> >>>>b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> >>>>index 8d0ac076d8e2..6ffb0517421a 100644
> >>>>--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> >>>>+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> >>>>@@ -163,13 +163,13 @@
> >>>> function = "avb";
> >>>> };
> >>>>
> >>>>- sdhi0_pins_3v3: sd0_3v3 {
> >>>>+ sdhi0_pins: sd0 {
> >>>> groups = "sdhi0_data4", "sdhi0_ctrl";
> >>>> function = "sdhi0";
> >>>> power-source = <3300>;
> >>>> };
> >>>>
> >>>>- sdhi0_pins_1v8: sd0_1v8 {
> >>>>+ sdhi0_pins_uhs: sd0 {
> >>>
> >>> I'm afraid the following will just override the props of the node
> >>>above
> >>>which is not what we ant.
> >>Thank you for pointing to this.
> >>
> >>This is my typo.
> >>I will rework the patch to have different node names.
> >
> > The patch had been already merged by Simon and was posted a s apart of
> >a pull request (if I don't mistake), so I guess an incremental patch
> >needed now...
> Thanks for clarification.
>
> I will make incremental patch.
Please do.
^ permalink raw reply
* arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings
From: Simon Horman @ 2016-11-30 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472635054-24372-1-git-send-email-geert+renesas@glider.be>
On Wed, Aug 31, 2016 at 11:17:34AM +0200, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, queued up for v4.11.
^ 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:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c9012fd-070b-6218-48e7-69b37f2559dd@redhat.com>
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?
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] arm64: dts: juno: Correct PCI IO window
From: liviu.dudau at arm.com @ 2016-11-30 10:04 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>
With the U-Boot patch that I have sent to the ML:
Tested-by: Liviu Dudau <Liviu.Dudau@arm.com>
also
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Best regards,
Liviu
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [RFC v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-11-30 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bec21998-b30c-4076-62bf-6b24c9dd1dd6@linaro.org>
Am Freitag, den 25.11.2016, 20:08 +0800 schrieb zhangfei:
>
> On 2016?11?25? 18:54, Philipp Zabel wrote:
> > Am Freitag, den 25.11.2016, 18:42 +0800 schrieb zhangfei:
> >> On 2016?11?25? 18:25, Philipp Zabel wrote:
> >>> Am Donnerstag, den 24.11.2016, 18:20 +0800 schrieb zhangfei:
> >>>> On 2016?11?24? 17:50, Philipp Zabel wrote:
> >>>>> Am Donnerstag, den 24.11.2016, 17:40 +0800 schrieb zhangfei:
> >>>>>> On 2016?11?24? 17:26, Philipp Zabel wrote:
> >>>>>>> Am Mittwoch, den 23.11.2016, 16:07 +0800 schrieb Zhangfei Gao:
> >>>>>>>> Add DT bindings documentation for hi3660 SoC reset controller.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >>>>>>>> ---
> >>>>>>>> .../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
> >>>>>>>> 1 file changed, 51 insertions(+)
> >>>>>>>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>>>>>>
> >>>>>>>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>>>>>> new file mode 100644
> >>>>>>>> index 0000000..250daf2
> >>>>>>>> --- /dev/null
> >>>>>>>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>>>>>> @@ -0,0 +1,51 @@
> >>>>>>>> +Hisilicon System Reset Controller
> >>>>>>>> +======================================
> >>>>>>>> +
> >>>>>>>> +Please also refer to reset.txt in this directory for common reset
> >>>>>>>> +controller binding usage.
> >>>>>>>> +
> >>>>>>>> +The reset controller registers are part of the system-ctl block on
> >>>>>>>> +hi3660 SoC.
> >>>>>>>> +
> >>>>>>>> +Required properties:
> >>>>>>>> +- compatible: should be
> >>>>>>>> + "hisilicon,hi3660-reset"
> >>>>>>>> +- #reset-cells: 1, see below
> >>>>>>>> +- hisi,rst-syscon: phandle of the reset's syscon.
> >>>>>>>> +- hisi,reset-bits: Contains the reset control register information
> >>>>>>>> + Should contain 2 cells for each reset exposed to
> >>>>>>>> + consumers, defined as:
> >>>>>>>> + Cell #1 : offset from the syscon register base
> >>>>>>>> + Cell #2 : bits position of the control register
> >>>>>>>> +
> >>>>>>>> +Example:
> >>>>>>>> + iomcu: iomcu at ffd7e000 {
> >>>>>>>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> >>>>>>>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> >>>>>>>> + };
> >>>>>>>> +
> >>>>>>>> + iomcu_rst: iomcu_rst_controller {
> >>>>>>> This should be
> >>>>>>> iomcu_rst: reset-controller {
> >>>>>>>
> >>>>>>>> + compatible = "hisilicon,hi3660-reset";
> >>>>>>>> + #reset-cells = <1>;
> >>>>>>>> + hisi,rst-syscon = <&iomcu>;
> >>>>>>>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> >>>>>>>> + 0x20 0x10 /* 1: i2c1 */
> >>>>>>>> + 0x20 0x20 /* 2: i2c2 */
> >>>>>>>> + 0x20 0x8000000>; /* 3: i2c6 */
> >>>>>>>> + };
> >>>>>>> The reset lines are controlled through iomcu bits, is there a reason not
> >>>>>>> to put the iomcu_rst node inside the iomcu node? That way the
> >>>>>>> hisi,rst-syscon property could be removed and the syscon could be
> >>>>>>> retrieved via the reset-controller parent node.
> >>>>>> iomcu is common registers, controls clock and reset, etc.
> >>>>>> So we use syscon, without mapping the registers everywhere.
> >>>>>> It is common case in hisilicon, same in hi6220.
> >>>>>>
> >>>>>> Also the #clock-cells and #reset-cells can not be put in the same node,
> >>>>>> if they are both using probe, since reset_probe will not be called.
> >>>>>>
> >>>>>> So we use hisi,rst-syscon as a general solution.
> >>>>> What I meant is this:
> >>>>>
> >>>>> iomcu: iomcu at ffd7e000 {
> >>>>> compatible = "hisilicon,hi3660-iomcu", "syscon", "simple-mfd";
> >>>>> reg = <0x0 0xffd7e000 0x0 0x1000>;
> >>>> #clock-cells = <1>;
> >>>>
> >>>> In my test, if there add #clock-cells = <1>, reset_probe will not be
> >>>> called any more.
> >>>> Since clk_probe is called first.
> >>>> No matter iomcu_rst is child node or not.
> >>> I don't understand this, does the clock driver bind to the iomcu node
> >>> using CLK_OF_DECLARE_DRIVER(..., "hisilicon,hi3660-iomcu", ...)?
> >> This method:CLK_OF_DECLARE_DRIVER is not prefered in clock,
> >> and we have to use probe instead, to make all driver build as modules as
> >> possible.
> >>
> >> For example hi3660.
> >> static struct platform_driver hi3660_clk_driver = {
> >> .probe = hi3660_clk_probe,
> >> .driver = {
> >> .name = "hi3660-clk",
> >> .of_match_table = hi3660_clk_match_table,
> >> },
> >> };
> > hi3660_clk_match_table contains the "hisilicon,hi3660-iomcu" compatible?
> > If so, you could call
> > of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > from hi3660_clk_probe instead of using "simple-mfd" to probe the iomcu
> > node's children.
>
> Not using simple-mfd:
>
> Like
> static const struct of_device_id hi3660_clk_match_table[] = {
> { .compatible = "hisilicon,hi3660-iomcu", },
> { }
> };
> MODULE_DEVICE_TABLE(of, hi3660_clk_match_table);
>
> static int hi3660_clk_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct device_node *np = pdev->dev.of_node;
> const struct of_device_id *of_id;
> enum hi3660_clk_type type;
>
> of_id = of_match_device(hi3660_clk_match_table, dev);
> if (!of_id)
> return -EINVAL;
> ~
> }
>
> If put iomcu_rst as child node, and set #clock-cells = <1> to iomcu,
> then hi3660_clk_probe is called, hi3660_reset_probe will not be called.
For hi3660_reset_probe to be called, you'll have to call
of_platform_populate to probe the hi3660-iomcu children in this case.
> So using "hisi,rst-syscon" as pointer does not have the issue.
I understand that, it still sounds to me like you are organizing the
device tree around limitations of the current code. Instead the device
tree should be organized to best describe the hardware, and the code
should be adapted to support that.
Of course, if you use the flat DT layout everywhere else, I won't try to
block the reset driver because of this issue. I'm just saying nested
nodes in the DT would better describe the real control flow.
regards
Philipp
^ permalink raw reply
* [RFC v2 PATCH 23/23] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-11-30 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129172234.GY14217@n2100.armlinux.org.uk>
On 29/11/16 17:22, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2016 at 12:40:05PM +0000, Vladimir Murzin wrote:
>> With this patch applied potentially any platform can be built in NOMMU
>> configurations if CONFIG_EXPERT is selected. However, there is no
>> guaranty that platform can successfully run such Image. So the main
>
> guarantee
>
>> motivation behind of this patch:
>> - bring build coverage for NOMMU configurations
>> - allow known working NOMMU platforms (like R-class) to be used
>> - pave a way to add support for single address space (aka 1:1 mapping)
>> for MMU platforms, so they can be usable in NOMMU configurations
>>
>> Cc: Hartley Sweeten <hsweeten@visionengravers.com>
>> Cc: Ryan Mallon <rmallon@gmail.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Cc: Alexander Shiyan <shc_work@mail.ru>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Sascha Hauer <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>> arch/arm/Kconfig | 21 +++++++++++++++++++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index e78c822..bc6f406 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -327,9 +327,9 @@ choice
>>
>> config ARCH_MULTIPLATFORM
>> bool "Allow multiple platforms to be selected"
>> - depends on MMU
>> + depends on MMU || EXPERT
>> select ARM_HAS_SG_CHAIN
>> - select ARM_PATCH_PHYS_VIRT
>> + select ARM_PATCH_PHYS_VIRT if MMU
>> select AUTO_ZRELADDR
>> select CLKSRC_OF
>> select COMMON_CLK
>> @@ -339,6 +339,23 @@ config ARCH_MULTIPLATFORM
>> select PCI_DOMAINS if PCI
>> select SPARSE_IRQ
>> select USE_OF
>> + help
>> + Please, read carefully if you've selected CONFIG_MMU=n!
>> +
>> + Multiplatform with !MMU configuration *is not* meant that
>> + kernel built to support every platform will boot on them. It
>> + is because physical address space layouts (particularly where
>> + RAM is located) are different between platforms and there is
>> + no MMU to work that around.
>> +
>> + You must specify where RAM start (via DRAM_BASE config
>> + option) and appropriate size of RAM (via DRAM_SIZE config
>> + option) which are valid for the platform you are building
>> + for.
>> +
>> + This feature is *EXPERIMENTAL*, please, consider building
>> + with CONFIG_MMU=y unless you know what you do or want to
>> + help with testing.
>
> Do you actually see this help text anywhere? I don't think multiple-choice
> options show help for individual choices.
>
Yes I can: "System Type" -> "ARM system type" -> "Allow multiple platforms to
be selected" -> "?". Probably not the best place, but I failed to find
anything better :(
Cheers
Vladimir
^ permalink raw reply
* [RFC v2 PATCH 08/23] ARM: NOMMU: implement secondary_startup_arm
From: Vladimir Murzin @ 2016-11-30 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129171432.GX14217@n2100.armlinux.org.uk>
On 29/11/16 17:14, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2016 at 12:39:50PM +0000, Vladimir Murzin wrote:
>> Mediatek's and Qualcomm's platform code has reference to
>> secondary_startup_arm and that breaks NOMMU build.
>
> This needs to explain why this is safe in the presence of EFM32.
>
It did not explode by pure luck M-class doesn't support SMP. The code needs to
include case for CONFIG_CPU_THUMBONLY. I'll include update in the next version.
Thanks
Vladimir
>> Cc: Russell King <linux@armlinux.org.uk>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>> ---
>> arch/arm/kernel/head-nommu.S | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
>> index 7317554..2ab026f 100644
>> --- a/arch/arm/kernel/head-nommu.S
>> +++ b/arch/arm/kernel/head-nommu.S
>> @@ -89,6 +89,12 @@ ENDPROC(stext)
>>
>> #ifdef CONFIG_SMP
>> .text
>> + .arm
>> +ENTRY(secondary_startup_arm)
>> + THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
>> + THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
>> + THUMB( .thumb ) @ switch to Thumb now.
>> + THUMB(1: )
>> ENTRY(secondary_startup)
>> /*
>> * Common entry point for secondary CPUs.
>> @@ -126,6 +132,7 @@ ENTRY(secondary_startup)
>> mov fp, #0
>> b secondary_start_kernel
>> ENDPROC(secondary_startup)
>> +ENDPROC(secondary_startup_arm)
>>
>> .type __secondary_data, %object
>> __secondary_data:
>> --
>> 1.7.9.5
>>
>
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Yao Qi @ 2016-11-30 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Hi, Dave,
On Fri, Nov 25, 2016 at 7:38 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> * No independent SVE vector length configuration per thread. This is
> planned, but will follow as a separate add-on series.
If I read "independent SVE vector length configuration per thread"
correctly, SVE vector length can be different in each thread, so the
size of vector registers is different too. In GDB, we describe registers
by "target description" which is per process, not per thread.
--
Yao (??)
^ 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