* [PATCH] cpufreq: s3c64xx: remove incorrect __init annotation
From: Krzysztof Kozlowski @ 2016-12-16 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216090625.2235668-1-arnd@arndb.de>
On Fri, Dec 16, 2016 at 10:06:15AM +0100, Arnd Bergmann wrote:
> s3c64xx_cpufreq_config_regulator is incorrectly annotated
> as __init, since the caller is also not init:
>
> WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator()
>
> With modern gcc versions, the function gets inline, so we don't
> see the warning, this only happens with gcc-4.6 and older.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/cpufreq/s3c64xx-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V9 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan
From: Agustin Vega-Frias @ 2016-12-16 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216162439.GA24673@red-moon>
Hi Lorenzo,
On 2016-12-16 11:24, Lorenzo Pieralisi wrote:
> On Wed, Dec 14, 2016 at 05:10:36PM -0500, Agustin Vega-Frias wrote:
>> ACPI extended IRQ resources may contain a Resource Source field to
>> specify
>> an alternate interrupt controller, attempting to map them as GSIs is
>> incorrect, so just disable the platform resource.
>>
>> Since this field is currently ignored, we make this change conditional
>> on CONFIG_ACPI_GENERIC_GSI to keep the current behavior on x86
>> platforms,
>> in case some existing ACPI tables are using this incorrectly.
>>
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>> drivers/acpi/resource.c | 17 ++++++++++++++++-
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 56241eb..76ca4e9 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -43,6 +43,18 @@ static inline bool
>> acpi_iospace_resource_valid(struct resource *res)
>> acpi_iospace_resource_valid(struct resource *res) { return true; }
>> #endif
>>
>> +#ifdef CONFIG_ACPI_GENERIC_GSI
>> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
>> +{
>> + return ext_irq->resource_source.string_length == 0;
>> +}
>> +#else
>> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
>> +{
>> + return true;
>> +}
>> +#endif
>
> Well, patch is simple there is not much to say other that on the
> firmware side I honestly do not see many options, either we remove the
> ifdeffery above and make the check unconditional (ie we do check on
> x86/ia64 too instead of always returning true) and see if things hold
> up
> on x86 (at least we try) or we will never know and will never be able
> to
> use this on x86 if there will ever be need.
>
> It would be certainly weird to find out that a descriptor has a
> resource_source pointer put there by mistake (because that's what we
> are
> talking about, things work on x86/ia64 by ignoring the resource_source
> pointer so any string there is just an unfortunate mistake AFAICS).
>
> I am quite tempted to remove the ifdef and make the is_gsi() check
> effective on
> x86/ia64 too.
I wouldn't be opposed to that. I added the #ifdef out of abundance of
caution,
but if the x86 folks agree and we can get sufficient testing to ensure
this
doesn't break anything I'd like to remove it too.
Thanks,
Agustin
>
> Lorenzo
>
>> +
>> static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len,
>> bool io)
>> {
>> u64 reslen = end - start + 1;
>> @@ -470,9 +482,12 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> + if (is_gsi(ext_irq))
>> + acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> ext_irq->triggering, ext_irq->polarity,
>> ext_irq->sharable, false);
>> + else
>> + acpi_dev_irqresource_disabled(res, 0);
>> break;
>> default:
>> res->flags = 0;
>> --
>> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
>> Linux Foundation Collaborative Project.
>>
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Russell King - ARM Linux @ 2016-12-16 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612161713.46770@pali>
On Fri, Dec 16, 2016 at 05:13:46PM +0100, Pali Roh?r wrote:
> On Friday 16 December 2016 16:40:30 Tony Lindgren wrote:
> > * Javier Martinez Canillas <javier@osg.samsung.com> [161216 04:54]:
> > > On 12/16/2016 09:48 AM, Pali Roh?r wrote:
> > > >>> saying that it cause problems which need to be properly fixed.
> > > >>> And if fixing them is harder and will take more time, then
> > > >>> correct option is to revert 008a2ebcd677 due to breaking
> > > >>> support for more devices.
> > > >>
> > > >> If you think that others boards may have the same issue, then
> > > >> you could add an empty chosen node to omap3.dtsi. As I said I
> > > >> think that in practice this will only be needed for the
> > > >> machines using NOLO but you are right that in theory you could
> > > >> boot them using other bootloaders and having an empty node
> > > >> doesn't cause any harm anyway.
> > > >
> > > > Should not be it part of any arm board? IIRC ATAG support is (or
> > > > was) not omap3 specified.
> > >
> > > Yes, but you were talking about commit 008a2ebcd677 which only
> > > removed skeleton.dtsi usage for OMAP3 boards. The same can be done
> > > for other SoCs in its top level dtsi for the SoC family of course.
> >
> > Yeah probaby best to add the empty chosen node to the ones that had
> > skeleton.dtsi removed.
>
> Ok. But still I think that it should be added globally to all arm board
> which can be booted by ATAG bootloader.
+1
> > And I think the code should print a warning if no chosen node is
> > found?
>
> Which code? Decompressor? Yes, it should but I do not know if at that
> time is (serial) console usable...
It isn't in multiplatform situations. Best if the kernel prints it,
because then it can be logged.
--
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 V9 1/3] ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan
From: Lorenzo Pieralisi @ 2016-12-16 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481753438-3905-2-git-send-email-agustinv@codeaurora.org>
On Wed, Dec 14, 2016 at 05:10:36PM -0500, Agustin Vega-Frias wrote:
> ACPI extended IRQ resources may contain a Resource Source field to specify
> an alternate interrupt controller, attempting to map them as GSIs is
> incorrect, so just disable the platform resource.
>
> Since this field is currently ignored, we make this change conditional
> on CONFIG_ACPI_GENERIC_GSI to keep the current behavior on x86 platforms,
> in case some existing ACPI tables are using this incorrectly.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/resource.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..76ca4e9 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -43,6 +43,18 @@ static inline bool acpi_iospace_resource_valid(struct resource *res)
> acpi_iospace_resource_valid(struct resource *res) { return true; }
> #endif
>
> +#ifdef CONFIG_ACPI_GENERIC_GSI
> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
> +{
> + return ext_irq->resource_source.string_length == 0;
> +}
> +#else
> +static inline bool is_gsi(struct acpi_resource_extended_irq *ext_irq)
> +{
> + return true;
> +}
> +#endif
Well, patch is simple there is not much to say other that on the
firmware side I honestly do not see many options, either we remove the
ifdeffery above and make the check unconditional (ie we do check on
x86/ia64 too instead of always returning true) and see if things hold up
on x86 (at least we try) or we will never know and will never be able to
use this on x86 if there will ever be need.
It would be certainly weird to find out that a descriptor has a
resource_source pointer put there by mistake (because that's what we are
talking about, things work on x86/ia64 by ignoring the resource_source
pointer so any string there is just an unfortunate mistake AFAICS).
I am quite tempted to remove the ifdef and make the is_gsi() check effective on
x86/ia64 too.
Lorenzo
> +
> static bool acpi_dev_resource_len_valid(u64 start, u64 end, u64 len, bool io)
> {
> u64 reslen = end - start + 1;
> @@ -470,9 +482,12 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + if (is_gsi(ext_irq))
> + acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> + else
> + acpi_dev_irqresource_disabled(res, 0);
> break;
> default:
> res->flags = 0;
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-16 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b6e8d3a-ec7a-db5d-dd0e-ef9d1480f80a@fivetechno.de>
Hello Markus,
On 12/16/2016 06:08 AM, Markus Reichl wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>
>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>> IOW if the problem exists it is already present in the mainline
>>>> kernel.
>>>
>>> Interesting. In the ChromeOS tree I see significantly higher voltages
>>> needed... Note that one might naively look at
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>
>>> 1362500, /* L0 2100 */
>>> 1312500, /* L1 2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead. See
>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>
>>> { 2100000,
>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>> 1275000, 1262500, 1250000, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>> 1200000, 1187500, 1175000, 1162500, 1150000,
>> 1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.
>
>>
>> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
>> along with name of tested board. Because the "Tested on XU3" is not
>> sufficient.
>
> If you point me to how to read these values out, I will publish them.
>
You can use the exynos-chipid driver posted by Pankaj. Apply patches 1 and
2 from this series (http://www.spinics.net/lists/arm-kernel/msg548384.html)
and then this diff to get the values of the registers that Krzysztof asked:
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index cf0128b18ee2..49fa76ec6d49 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -22,6 +22,9 @@
#define EXYNOS_MAINREV_MASK (0xF << 0)
#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
+#define EXYNOS_PKG_ID 0x04
+#define EXYNOS_AUX_INFO 0x1C
+
static const struct exynos_soc_id {
const char *name;
unsigned int id;
@@ -71,6 +74,8 @@ int __init exynos_chipid_early_init(void)
const struct of_device_id *match;
u32 product_id;
u32 revision;
+ u32 pkg_id;
+ u32 aux_info;
np = of_find_matching_node_and_match(NULL,
of_exynos_chipid_ids, &match);
@@ -84,6 +89,8 @@ int __init exynos_chipid_early_init(void)
product_id = readl_relaxed(exynos_chipid_base);
revision = product_id & EXYNOS_REV_MASK;
+ pkg_id = readl_relaxed(exynos_chipid_base + EXYNOS_PKG_ID);
+ aux_info = readl_relaxed(exynos_chipid_base + EXYNOS_AUX_INFO);
iounmap(exynos_chipid_base);
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
@@ -100,8 +107,8 @@ int __init exynos_chipid_early_init(void)
soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
- pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
- product_id_to_soc_id(product_id), revision);
+ pr_info("Exynos: CPU[%s] CPU_REV[0x%x] PKG_ID[0x%x] AUX_INFO[0x%x] \n",
+ product_id_to_soc_id(product_id), revision, pkg_id, aux_info);
soc_dev = soc_device_register(soc_dev_attr);
if (IS_ERR(soc_dev)) {
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply related
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Tony Lindgren @ 2016-12-16 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612161713.46770@pali>
* Pali Roh?r <pali.rohar@gmail.com> [161216 08:14]:
> On Friday 16 December 2016 16:40:30 Tony Lindgren wrote:
> > * Javier Martinez Canillas <javier@osg.samsung.com> [161216 04:54]:
> > > On 12/16/2016 09:48 AM, Pali Roh?r wrote:
> > > >>> saying that it cause problems which need to be properly fixed.
> > > >>> And if fixing them is harder and will take more time, then
> > > >>> correct option is to revert 008a2ebcd677 due to breaking
> > > >>> support for more devices.
> > > >>
> > > >> If you think that others boards may have the same issue, then
> > > >> you could add an empty chosen node to omap3.dtsi. As I said I
> > > >> think that in practice this will only be needed for the
> > > >> machines using NOLO but you are right that in theory you could
> > > >> boot them using other bootloaders and having an empty node
> > > >> doesn't cause any harm anyway.
> > > >
> > > > Should not be it part of any arm board? IIRC ATAG support is (or
> > > > was) not omap3 specified.
> > >
> > > Yes, but you were talking about commit 008a2ebcd677 which only
> > > removed skeleton.dtsi usage for OMAP3 boards. The same can be done
> > > for other SoCs in its top level dtsi for the SoC family of course.
> >
> > Yeah probaby best to add the empty chosen node to the ones that had
> > skeleton.dtsi removed.
>
> Ok. But still I think that it should be added globally to all arm board
> which can be booted by ATAG bootloader.
Hmm you mean by the decompressor?
> > And I think the code should print a warning if no chosen node is
> > found?
>
> Which code? Decompressor? Yes, it should but I do not know if at that
> time is (serial) console usable...
Oh right, never mind..
Tony
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Pali Rohár @ 2016-12-16 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216154029.GF4920@atomide.com>
On Friday 16 December 2016 16:40:30 Tony Lindgren wrote:
> * Javier Martinez Canillas <javier@osg.samsung.com> [161216 04:54]:
> > On 12/16/2016 09:48 AM, Pali Roh?r wrote:
> > >>> saying that it cause problems which need to be properly fixed.
> > >>> And if fixing them is harder and will take more time, then
> > >>> correct option is to revert 008a2ebcd677 due to breaking
> > >>> support for more devices.
> > >>
> > >> If you think that others boards may have the same issue, then
> > >> you could add an empty chosen node to omap3.dtsi. As I said I
> > >> think that in practice this will only be needed for the
> > >> machines using NOLO but you are right that in theory you could
> > >> boot them using other bootloaders and having an empty node
> > >> doesn't cause any harm anyway.
> > >
> > > Should not be it part of any arm board? IIRC ATAG support is (or
> > > was) not omap3 specified.
> >
> > Yes, but you were talking about commit 008a2ebcd677 which only
> > removed skeleton.dtsi usage for OMAP3 boards. The same can be done
> > for other SoCs in its top level dtsi for the SoC family of course.
>
> Yeah probaby best to add the empty chosen node to the ones that had
> skeleton.dtsi removed.
Ok. But still I think that it should be added globally to all arm board
which can be booted by ATAG bootloader.
> And I think the code should print a warning if no chosen node is
> found?
Which code? Decompressor? Yes, it should but I do not know if at that
time is (serial) console usable...
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161216/997b8f16/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Laurent Pinchart @ 2016-12-16 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481814682-31780-3-git-send-email-appanad@xilinx.com>
Hi Kedareswara,
Thank you for the patch.
On Thursday 15 Dec 2016 20:41:21 Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 43 ++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c
> b/drivers/dma/xilinx/xilinx_dma.c index 736c2a3..4f3fa94 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1087,23 +1087,33 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan)
> tail_segment->phys);
> } else {
> struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>
> if (chan->desc_submitcount < chan->num_frms)
> i = chan->desc_submitcount;
I don't get this. i seems to index into a segment start address array, but
gets initialized with a variable documented as "Descriptor h/w submitted
count". I'm not familiar with the hardware, but it makes no sense to me.
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
Isn't it an issue to write the descriptors only after calling
xilinx_dma_start() ?
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> +
XILINX_VDMA_REG_START_ADDRESS_64(i++),
> + segment->hw.buf_addr,
> + segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> +
XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
I assume the size of the start address array to be limited by the hardware,
but I don't see how this code prevents from overflowing this.
The whole function is very difficult to understand, it probably requires a
rewrite.
> + last = segment;
> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;
> + if (list_empty(&chan->pending_list))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct
xilinx_dma_tx_descriptor,
> + node);
> }
>
> if (!last)
> @@ -1114,14 +1124,13 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan) vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> last->hw.stride);
> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
> +
> + chan->desc_submitcount += j;
> + chan->desc_pendingcount -= j;
> }
>
> chan->idle = false;
> if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submitcount++;
> - chan->desc_pendingcount--;
> if (chan->desc_submitcount == chan->num_frms)
> chan->desc_submitcount = 0;
> } else {
While at it, can you merge this into the previous if (chan->has_sg) { ... }
else { ... } ? Having them separate is confusing.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Tony Lindgren @ 2016-12-16 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b779429-8ce4-a49b-38e4-573b28a7c05f@osg.samsung.com>
* Javier Martinez Canillas <javier@osg.samsung.com> [161216 04:54]:
> On 12/16/2016 09:48 AM, Pali Roh?r wrote:
> >>> saying that it cause problems which need to be properly fixed. And
> >>> if fixing them is harder and will take more time, then correct
> >>> option is to revert 008a2ebcd677 due to breaking support for more
> >>> devices.
> >>
> >> If you think that others boards may have the same issue, then you
> >> could add an empty chosen node to omap3.dtsi. As I said I think that
> >> in practice this will only be needed for the machines using NOLO but
> >> you are right that in theory you could boot them using other
> >> bootloaders and having an empty node doesn't cause any harm anyway.
> >
> > Should not be it part of any arm board? IIRC ATAG support is (or was)
> > not omap3 specified.
> >
>
> Yes, but you were talking about commit 008a2ebcd677 which only removed
> skeleton.dtsi usage for OMAP3 boards. The same can be done for other
> SoCs in its top level dtsi for the SoC family of course.
Yeah probaby best to add the empty chosen node to the ones that had
skeleton.dtsi removed.
And I think the code should print a warning if no chosen node is
found?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Laurent Pinchart @ 2016-12-16 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481814682-31780-2-git-send-email-appanad@xilinx.com>
Hi Kedareswara,
Thank you for the patch.
On Thursday 15 Dec 2016 20:41:20 Kedareswara rao Appana wrote:
> Add channel idle state to ensure that dma descriptor is not
> submitted when VDMA engine is in progress.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c
> b/drivers/dma/xilinx/xilinx_dma.c index 8288fe4..736c2a3 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -321,6 +321,7 @@ struct xilinx_dma_tx_descriptor {
> * @cyclic: Check for cyclic transfers.
> * @genlock: Support genlock mode
> * @err: Channel has errors
> + * @idle: Check for channel idle
> * @tasklet: Cleanup work after irq
> * @config: Device configuration info
> * @flush_on_fsync: Flush on Frame sync
> @@ -351,6 +352,7 @@ struct xilinx_dma_chan {
> bool cyclic;
> bool genlock;
> bool err;
> + bool idle;
> struct tasklet_struct tasklet;
> struct xilinx_vdma_config config;
> bool flush_on_fsync;
> @@ -966,6 +968,7 @@ static void xilinx_dma_halt(struct xilinx_dma_chan
> *chan) chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
> chan->err = true;
> }
> + chan->idle = true;
> }
>
> /**
> @@ -1007,6 +1010,9 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan)
> if (chan->err)
> return;
>
> + if (!chan->idle)
> + return;
Don't you need to perform the same check for the DMA and CDMA channels ? If
so, shouldn't this be moved to common code ?
There's another problem (not strictly introduced by this patch) I wanted to
mention. The append_desc_queue() function, called from your tx_submit handler,
appends descriptors to the pending_list. The DMA engine API states that a
transfer submitted by tx_submit will not be executed until .issue_pending() is
called. However, if a transfer is in progress at tx_submit time, I believe
that the IRQ handler, at transfer completion, will start the next transfer
from the pending_list even if .issue_pending() hasn't been called for it.
> if (list_empty(&chan->pending_list))
> return;
Now that you catch busy channels with a software flag, do you still need the
xilinx_dma_is_running() and xilinx_dma_is_idle() checks ? Three different
checks for the same or very similar conditions are confusing, if you really
need them you should document clearly how they differ.
> @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan) vdma_desc_write(chan, XILINX_DMA_REG_VSIZE,
> last->hw.vsize);
> }
>
> + chan->idle = false;
(and this too)
> if (!chan->has_sg) {
> list_del(&desc->node);
> list_add_tail(&desc->node, &chan->active_list);
> @@ -1447,6 +1454,7 @@ static irqreturn_t xilinx_dma_irq_handler(int irq,
> void *data) if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> + chan->idle = true;
> chan->start_transfer(chan);
> spin_unlock(&chan->lock);
> }
> @@ -2327,6 +2335,7 @@ static int xilinx_dma_chan_probe(struct
> xilinx_dma_device *xdev, chan->has_sg = xdev->has_sg;
> chan->desc_pendingcount = 0x0;
> chan->ext_addr = xdev->ext_addr;
> + chan->idle = true;
>
> spin_lock_init(&chan->lock);
> INIT_LIST_HEAD(&chan->pending_list);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Alexandre Torgue @ 2016-12-16 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58540199.6000002@arm.com>
Hi,
On 12/16/2016 04:00 PM, Vladimir Murzin wrote:
> Hi Alexandre,
>
> On 16/12/16 14:57, Alexandre Torgue wrote:
>> Hi Vladimir,
>>
>> On 12/13/2016 02:45 PM, Vladimir Murzin wrote:
>>> Hi,
>>>
>>> It seem that addition of cache support for M-class cpus uncovered
>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>> always consistent; however, for R/M classes of cpu memory can be
>>> covered by MPU which in turn might configure RAM as Normal
>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>> friends, since data can stuck in caches now or be buffered.
>>>
>>> This patch set is trying to address the issue by providing region of
>>> memory suitable for consistent DMA operations. It is supposed that such
>>> region is marked by MPU as non-cacheable. Since we have MPU support in
>>> Linux for R-class only and M-class setting MPU in bootloader, proposed
>>> interface to advertise such memory is via "memdma=size at start" command
>>> line option, to avoid clashing with normal memory (which usually comes
>>> from dts) it'd be safer to use it together with "mem=" command line
>>> option. Meanwhile, I'm open to suggestions for the better way telling
>>> Linux of such memory.
>>>
>>> For configuration without cache support (like Cortex-M3/M4) dma
>>> operations are forced to be coherent and wired with dma-noop. Such
>>> decision is made based on cacheid global variable. In case cpu
>>> supports caches and no coherent memory region is given - dma is
>>> disallowed. Probably, some other important checks are missing, so I'll
>>> all my ears :)
>>>
>>> To make life easier NOMMU dma operations are kept in separate
>>> compilation unit.
>>>
>>> Thanks!
>>>
>>> Changelog:
>>>
>>> RFC v1 -> RFC v2
>>> - s/dmac_unmap_area/dmac_map_area in __dma_page_cpu_to_dev()
>>> - removed unrelated changes in nommu.c
>>>
>>> Vladimir Murzin (3):
>>> ARM: NOMMU: introduce dma operations for noMMU
>>> ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>> ARM: dma-mapping: remove traces of NOMMU code
>>>
>>> arch/arm/include/asm/dma-mapping.h | 3 +-
>>> arch/arm/mm/Kconfig | 2 +-
>>> arch/arm/mm/Makefile | 5 +-
>>> arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
>>> arch/arm/mm/dma-mapping.c | 26 +---
>>> arch/arm/mm/mm.h | 3 +
>>> arch/arm/mm/nommu.c | 6 +
>>> 7 files changed, 278 insertions(+), 29 deletions(-)
>>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>
>>
>> First, thanks for this series.
>>
>> I tested it on stm32f746 platform. Main issues related to cache and DMA are fixed but I still have an issue using dma_zalloc_alloc API. Allocated memory is not set to zero.
>> Can you have a look on it please?
>
> Thanks for testing! I think following diff should fix dma_zalloc_alloc():
Yes. With the patch below, it works fine.
Thanks
Alex
>
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index f92d98a..1f97bb8 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -38,6 +38,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
>
> ptr = (void *)gen_pool_alloc(dma_pool, size);
> if (ptr) {
> + memset(ptr, 0, size);
> *dma_handle = __pa(ptr);
> dmac_flush_range(ptr, ptr + size);
> outer_flush_range(__pa(ptr), __pa(ptr) + size);
>
>
> Cheers
> Vladimir
>
>>
>> Thanks
>> Alex
>>
>>
>
^ permalink raw reply
* [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2016-12-16 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82f0d72e-7029-ad88-3e44-ab48784297fa@st.com>
Hi Alexandre,
On 16/12/16 14:57, Alexandre Torgue wrote:
> Hi Vladimir,
>
> On 12/13/2016 02:45 PM, Vladimir Murzin wrote:
>> Hi,
>>
>> It seem that addition of cache support for M-class cpus uncovered
>> latent bug in DMA usage. NOMMU memory model has been treated as being
>> always consistent; however, for R/M classes of cpu memory can be
>> covered by MPU which in turn might configure RAM as Normal
>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>> friends, since data can stuck in caches now or be buffered.
>>
>> This patch set is trying to address the issue by providing region of
>> memory suitable for consistent DMA operations. It is supposed that such
>> region is marked by MPU as non-cacheable. Since we have MPU support in
>> Linux for R-class only and M-class setting MPU in bootloader, proposed
>> interface to advertise such memory is via "memdma=size at start" command
>> line option, to avoid clashing with normal memory (which usually comes
>> from dts) it'd be safer to use it together with "mem=" command line
>> option. Meanwhile, I'm open to suggestions for the better way telling
>> Linux of such memory.
>>
>> For configuration without cache support (like Cortex-M3/M4) dma
>> operations are forced to be coherent and wired with dma-noop. Such
>> decision is made based on cacheid global variable. In case cpu
>> supports caches and no coherent memory region is given - dma is
>> disallowed. Probably, some other important checks are missing, so I'll
>> all my ears :)
>>
>> To make life easier NOMMU dma operations are kept in separate
>> compilation unit.
>>
>> Thanks!
>>
>> Changelog:
>>
>> RFC v1 -> RFC v2
>> - s/dmac_unmap_area/dmac_map_area in __dma_page_cpu_to_dev()
>> - removed unrelated changes in nommu.c
>>
>> Vladimir Murzin (3):
>> ARM: NOMMU: introduce dma operations for noMMU
>> ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>> ARM: dma-mapping: remove traces of NOMMU code
>>
>> arch/arm/include/asm/dma-mapping.h | 3 +-
>> arch/arm/mm/Kconfig | 2 +-
>> arch/arm/mm/Makefile | 5 +-
>> arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
>> arch/arm/mm/dma-mapping.c | 26 +---
>> arch/arm/mm/mm.h | 3 +
>> arch/arm/mm/nommu.c | 6 +
>> 7 files changed, 278 insertions(+), 29 deletions(-)
>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>
>
> First, thanks for this series.
>
> I tested it on stm32f746 platform. Main issues related to cache and DMA are fixed but I still have an issue using dma_zalloc_alloc API. Allocated memory is not set to zero.
> Can you have a look on it please?
Thanks for testing! I think following diff should fix dma_zalloc_alloc():
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index f92d98a..1f97bb8 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -38,6 +38,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
ptr = (void *)gen_pool_alloc(dma_pool, size);
if (ptr) {
+ memset(ptr, 0, size);
*dma_handle = __pa(ptr);
dmac_flush_range(ptr, ptr + size);
outer_flush_range(__pa(ptr), __pa(ptr) + size);
Cheers
Vladimir
>
> Thanks
> Alex
>
>
^ permalink raw reply related
* [RFC v2 PATCH 0/3] Fix dma_alloc_coherent() and friends for NOMMU
From: Alexandre Torgue @ 2016-12-16 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636704-18948-1-git-send-email-vladimir.murzin@arm.com>
Hi Vladimir,
On 12/13/2016 02:45 PM, Vladimir Murzin wrote:
> Hi,
>
> It seem that addition of cache support for M-class cpus uncovered
> latent bug in DMA usage. NOMMU memory model has been treated as being
> always consistent; however, for R/M classes of cpu memory can be
> covered by MPU which in turn might configure RAM as Normal
> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
> friends, since data can stuck in caches now or be buffered.
>
> This patch set is trying to address the issue by providing region of
> memory suitable for consistent DMA operations. It is supposed that such
> region is marked by MPU as non-cacheable. Since we have MPU support in
> Linux for R-class only and M-class setting MPU in bootloader, proposed
> interface to advertise such memory is via "memdma=size at start" command
> line option, to avoid clashing with normal memory (which usually comes
> from dts) it'd be safer to use it together with "mem=" command line
> option. Meanwhile, I'm open to suggestions for the better way telling
> Linux of such memory.
>
> For configuration without cache support (like Cortex-M3/M4) dma
> operations are forced to be coherent and wired with dma-noop. Such
> decision is made based on cacheid global variable. In case cpu
> supports caches and no coherent memory region is given - dma is
> disallowed. Probably, some other important checks are missing, so I'll
> all my ears :)
>
> To make life easier NOMMU dma operations are kept in separate
> compilation unit.
>
> Thanks!
>
> Changelog:
>
> RFC v1 -> RFC v2
> - s/dmac_unmap_area/dmac_map_area in __dma_page_cpu_to_dev()
> - removed unrelated changes in nommu.c
>
> Vladimir Murzin (3):
> ARM: NOMMU: introduce dma operations for noMMU
> ARM: NOMMU: set ARM_DMA_MEM_BUFFERABLE for M-class cpus
> ARM: dma-mapping: remove traces of NOMMU code
>
> arch/arm/include/asm/dma-mapping.h | 3 +-
> arch/arm/mm/Kconfig | 2 +-
> arch/arm/mm/Makefile | 5 +-
> arch/arm/mm/dma-mapping-nommu.c | 262 ++++++++++++++++++++++++++++++++++++
> arch/arm/mm/dma-mapping.c | 26 +---
> arch/arm/mm/mm.h | 3 +
> arch/arm/mm/nommu.c | 6 +
> 7 files changed, 278 insertions(+), 29 deletions(-)
> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>
First, thanks for this series.
I tested it on stm32f746 platform. Main issues related to cache and DMA
are fixed but I still have an issue using dma_zalloc_alloc API.
Allocated memory is not set to zero.
Can you have a look on it please?
Thanks
Alex
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-16 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216124748.rkvnnlo4x5onzpvk@lukather>
16.12.2016, 20:47, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Dec 09, 2016 at 07:49:00PM +0800, Icenowy Zheng wrote:
>> ?2016?12?9? ??4:07? Maxime Ripard <maxime.ripard@free-electrons.com>???
>> ?>
>> ?> On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
>> ?> > Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
>> ?> > has a dedicated enable pin (PL8 in the reference design).
>> ?> >
>> ?> > Enable the pin in the same way as the WLAN enable pins.
>> ?> >
>> ?> > Tested on an A33 Q8 tablet with RTL8703AS.
>> ?> >
>> ?> > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?> > ---
>> ?> >
>> ?> > This patch should be coupled with the uart1 node patch I send before:
>> ?> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
>> ?> >
>> ?> > For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
>> ?> > https://github.com/lwfinger/rtl8723bs_bt
>> ?> >
>> ?> >? arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
>> ?> >? 1 file changed, 1 insertion(+), 1 deletion(-)
>> ?> >
>> ?> > diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
>> ?> > index c676940..4aeb5bb 100644
>> ?> > --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
>> ?> > +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
>> ?> > @@ -88,7 +88,7 @@
>> ?> >
>> ?> >? &r_pio {
>> ?> >? wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
>> ?> > - pins = "PL6", "PL7", "PL11";
>> ?> > + pins = "PL6", "PL7", "PL8", "PL11";
>> ?> >? function = "gpio_in";
>> ?> >? bias-pull-up;
>> ?> >? };
>> ?>
>> ?> There's several things wrong here. The first one is that you rely
>> ?> solely on the pinctrl state to maintain a reset line. This is very
>> ?> fragile (especially since the GPIO pinctrl state are likely to go away
>> ?> at some point), but it also means that if your driver wants to recover
>> ?> from that situation at some point, it won't work.
>> ?>
>> ?> The other one is that the bluetooth and wifi chips are two devices in
>> ?> linux, and you assign that pin to the wrong device (wifi).
>> ?>
>> ?> rfkill-gpio is made just for that, so please use it.
>>
>> ?The GPIO is not for the radio, but for the full Bluetooth part.
>
> I know.
>
>> ?If it's set to 0, then the bluetooth part will reset, and the
>> ?hciattach will fail.
>
> Both rfkill-gpio and rfkill-regulator will shutdown when called
> (either by poking the reset pin or shutting down the regulator), so
> that definitely seems like an expected behavior to put the device in
> reset.
>
>> ?The BSP uses this as a rfkill, and the result is that the bluetooth
>> ?on/off switch do not work properly.
>
> Then rfkill needs fixing, but working around it by hoping that the
> core will probe an entirely different device, and enforcing a default
> that the rest of the kernel might or might not change is both fragile
> and wrong.
I think a rfkill-gpio here works just like the BSP rfkill...
The real problem is that the Realtek UART bluetooth driver is a userspace
program (a modified hciattach), which is not capable of the GPIO reset...
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Bartlomiej Zolnierkiewicz @ 2016-12-16 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481897676-13578-1-git-send-email-m.szyprowski@samsung.com>
Hi,
On Friday, December 16, 2016 03:14:36 PM Marek Szyprowski wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings and allow to make cleanup of the existing code and device tree
> files, lets mark Samsung Exynos SoC platform bindings as unstable. This
> means that bindings can may change at any time and users should use the
> dtb file compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
This change is long overdue..
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> Documentation/devicetree/bindings/arm/samsung/exynos.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos.txt b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
> new file mode 100644
> index 000000000000..0c606f4c6e85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
> @@ -0,0 +1,12 @@
> +Samsung Exynos SoC Family Device Tree Bindings
> +---------------------------------------------------------------
> +
> +Work in progress statement:
> +
> +Device tree files and bindings applying to Samsung Exynos SoCs and boards are
> +considered "unstable". Any Samsung Exynos device tree binding may change at any
> +time. Be sure to use a device tree binary and a kernel image generated from the
> +same source tree.
> +
> +Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
> +stable binding/ABI.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Javier Martinez Canillas @ 2016-12-16 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481897676-13578-1-git-send-email-m.szyprowski@samsung.com>
Hello Marek,
On 12/16/2016 11:14 AM, Marek Szyprowski wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings and allow to make cleanup of the existing code and device tree
> files, lets mark Samsung Exynos SoC platform bindings as unstable. This
> means that bindings can may change at any time and users should use the
> dtb file compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
I completely agree with you on this.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* jemalloc testsuite stalls in memset
From: Andreas Schwab @ 2016-12-16 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216063940.GA1334@bbox>
On Dez 16 2016, Minchan Kim <minchan@kernel.org> wrote:
> Below helps?
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index e10a4fe..dc37c9a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1611,6 +1611,7 @@ int madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> tlb->fullmm);
> orig_pmd = pmd_mkold(orig_pmd);
> orig_pmd = pmd_mkclean(orig_pmd);
> + orig_pmd = pmd_wrprotect(orig_pmd);
>
> set_pmd_at(mm, addr, pmd, orig_pmd);
> tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
Thanks, this fixes the issue (tested with 4.9).
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Marek Szyprowski @ 2016-12-16 14:14 UTC (permalink / raw)
To: linux-arm-kernel
Samsung Exynos SoCs and boards related bindings evolved since the initial
introduction, but initially the bindings were minimal and a bit incomplete
(they never described all the hardware modules available in the SoCs).
Since then some significant (not fully compatible) changes have been
already committed a few times (like gpio replaced by pinctrl, display ddc,
mfc reserved memory, some core clocks added to various hardware modules,
added more required nodes).
On the other side there are no boards which have device tree embedded in
the bootloader. Device tree blob is always compiled from the kernel tree
and updated together with the kernel image.
Thus to avoid further adding a bunch of workarounds for old/missing
bindings and allow to make cleanup of the existing code and device tree
files, lets mark Samsung Exynos SoC platform bindings as unstable. This
means that bindings can may change at any time and users should use the
dtb file compiled from the same kernel source tree as the kernel image.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
Documentation/devicetree/bindings/arm/samsung/exynos.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos.txt b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
new file mode 100644
index 000000000000..0c606f4c6e85
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
@@ -0,0 +1,12 @@
+Samsung Exynos SoC Family Device Tree Bindings
+---------------------------------------------------------------
+
+Work in progress statement:
+
+Device tree files and bindings applying to Samsung Exynos SoCs and boards are
+considered "unstable". Any Samsung Exynos device tree binding may change at any
+time. Be sure to use a device tree binary and a kernel image generated from the
+same source tree.
+
+Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
+stable binding/ABI.
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhong jiang @ 2016-12-16 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216123512.GF13191@arm.com>
On 2016/12/16 20:35, Will Deacon wrote:
> On Fri, Dec 16, 2016 at 05:10:05PM +0800, zhong jiang wrote:
>> On 2016/12/14 22:19, zhongjiang wrote:
>>> From: zhong jiang <zhongjiang@huawei.com>
>>>
>>> when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
>>> fuctions should not be use. therefore, we add the dependency.
>>>
>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 969ef88..694ca73 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
>>>
>>> config ARCH_WANT_HUGE_PMD_SHARE
>>> def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
>>> + depends on HUGETLB_PAGE
>>>
>>> config ARCH_HAS_CACHE_LINE_SIZE
>>> def_bool y
>> Hi,
>> I still think it is a issue. Perhaps above changelog is unclear. Further explain is as follows.
>> when hugetlb_pages is disable and arch_want_huge_pmd_share is enable, we maybe call
>> huge_pmd_sahre in hugetlbpage.c, but the function actually is not definition as it is not
>> exported. is it right ??
> The only users of ARCH_WANT_HUGE_PMD_SHARE on arm64 are:
>
> arch/arm64/mm/hugetlbpage.c: if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
> mm/hugetlb.c:#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
> mm/hugetlb.c:#else /* !CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
> mm/hugetlb.c:#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
>
> and neither of those files are compiled if !HUGETLB_PAGE.
>
> Are you actually seeing a problem here?
>
> Will
>
> .
>
I got it. Please forget the stupid patch and my stupid comments.
but the first patch look reasonable. Is it accepted ?
Thanks
zhongjiang
^ permalink raw reply
* [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
From: Robin Murphy @ 2016-12-16 13:19 UTC (permalink / raw)
To: linux-arm-kernel
The current SMR masking support using a 2-cell iommu-specifier is
primarily intended to handle individual masters with large and/or
complex Stream ID assignments; it quickly gets a bit clunky in other SMR
use-cases where we just want to consistently mask out the same part of
every Stream ID (e.g. for MMU-500 configurations where the appended TBU
number gets in the way unnecessarily). Let's add a new property to allow
a single global mask value to better fit the latter situation.
CC: Stuart Yoder <stuart.yoder@nxp.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
Compile-tested only...
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 ++++++++
drivers/iommu/arm-smmu.c | 4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index e862d1485205..98f5cbe5fdb4 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -60,6 +60,14 @@ conditions.
aliases of secure registers have to be used during
SMMU configuration.
+- stream-match-mask : Specifies a fixed SMR mask value to combine with
+ the Stream ID value from every iommu-specifier. This
+ may be used instead of an "#iommu-cells" value of 2
+ when there is no need for per-master SMR masks, but
+ it is still desired to mask some portion of every
+ Stream ID (e.g. for certain MMU-500 configurations
+ given globally unique external IDs).
+
** Deprecated properties:
- mmu-masters (deprecated in favour of the generic "iommus" binding) :
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f7281444551..f1abcb7dde36 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
{
- u32 fwid = 0;
+ u32 mask, fwid = 0;
if (args->args_count > 0)
fwid |= (u16)args->args[0];
if (args->args_count > 1)
fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
+ else if (!of_property_read_u32(args->np, "stream-match-mask", &mask))
+ fwid |= (u16)mask << SMR_MASK_SHIFT;
return iommu_fwspec_add_ids(dev, &fwid, 1);
}
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH v8 0/8] Introducing Exynos ChipId driver
From: Marek Szyprowski @ 2016-12-16 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-1-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj
On 2016-12-10 14:08, Pankaj Dubey wrote:
> Each Exynos SoC has ChipID block which can give information about SoC's
> product Id and revision number.
>
> This patch series introduces Exynos Chipid SoC driver. At the same time
> it reduces dependency of mach-exynos files from plat-samsung, by removing
> soc_is_exynosMMMM and samsung_rev API. Instead of it now we can use
> soc_device_match API proposed by Arnd and getting discussed in thread [1].
>
> Until now we are using static mapping of Exynos Chipid and using this static
> mapping to know about SoC name and revision via soc_is_exynosMMMM macro. This
> is quite cumbersome and every time new ARMv7 based Exynos SoC supports lands in
> mainline a bunch of such new macros needs to be added. Quite long back during
> support of Exynos5260 it has been discussed to solve this problem.
>
> To solve this issue this patchset replaces use of soc_is_exynosMMMM by either
> of_machine_is_compatible or soc_device_match depending upon usecase.
>
> I have tested this patch series on Exynos4210 based Origen board for normal SMP
> boot.
>
>
> Although I submitted this series as a whole of 8 patchsets, following are dependency
> details among the patches.
>
> Patch 1/8 can be taken without any dependency on other patches.
> Patch 2/8 and 3/8 has dependency on 1/8 and can be taken along with 1/8.
> Patch 4/8 has no dependency and can be taken without chipid driver patch 1/8.
> Patch 5/8 has depency on 1/8
> Patch 6/8 has no dependency and can be taken without any other patches.
> Patch 7/8 has dependency on 6/8 and 1/8
> Patch 8/8 has dependency on rest of patches
Which kernel should I use as a base for applying those patches? I wanted
to test them,
but I got conflicts both for v4.9 and current linux-next (next-20161216).
> [1]: https://patchwork.kernel.org/patch/9361389/
>
> Revision 7 and it's discussion can be found here:
> - https://www.spinics.net/lists/arm-kernel/msg540790.html
>
> Revision 6 and it's discussion can be found here:
> - https://lkml.org/lkml/2016/5/25/101
>
> Revision 5 and it's discussion can be found here:
> - http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310046.html
>
> Revision 4 and it's discussion can be found here:
> - https://lkml.org/lkml/2014/12/3/115
>
> Changes since v7:
> - Added ARM64 based Exynos7 and Exynos5433 support in chipid driver.
> - Removed Exynos4415 support from chipid driver, as exynos4415 has been removed from tree
> - Added patch to enable chipid driver for ARM64 based Exynos platform
> - Addressed review comments from Arnd for firmware.c, platsmp.c and pm.c files/
> - Splitted changes in firmware.c, platsmp.c and pm.c in separate patches
> for better code review
> - Included suggested code improvement in exynos-chipid.c from Marek Szyprowski
>
> Chances since v6:
> - Removed platform driver from chipid, instead use early_init to register soc_device
> - Removed export functions from exynos chipid driver
> - Replace soc_is_exynosMMMM via either of_machine_is_compatible or soc_device_match in
> files in arm/mach-exynos folder
> - This patchset depends on the following patch series by Geert Uytterhoeven. This series
> includes patch which introduces soc_device_match.
> http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1261739.html
> - Rebased on latest krzk/for-next branch and retested.
>
> Change since v5:
> - Addressed Rob's review comments.
> - Rebased on latest krzk/for-next branch and retested.
>
> Changes since v4:
> - Removed custom sysfs entries as they were not providing any new information
> as pointed out by Arnd.
> - Removed functions exporting product_id and revision, instead we will export
> exynos_chipid_info structure. It will be helpfull when we need to provide more
> fields of chipid outside of chipid, as commented by Yadwinder
> - Converted all funcions as __init.
>
> Change since v3:
> - This patch set contains 5/6 and 6/6 patch from v3 series.
> - Made EXYNOS_CHIPID config option non-user selectable,
> as suggested by Tomasz Figa.
> - Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
> suggested by Tomasz Figa.
> - Made local variables static in chipid driver.
> - Added existing SoC's product id's.
> - Added platform driver support.
>
> Changes since v2:
> - Reorganized patches as suggested by Tomasz Figa.
> - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.
>
> Pankaj Dubey (8):
> soc: samsung: add exynos chipid driver support
> ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
> ARM64: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
> ARM: EXYNOS: refactor firmware specific routines
> ARM: EXYNOS: refactor power management specific routines
> ARM: EXYNOS: remove secondary startup initialization from
> smp_prepare_cpus
> ARM: EXYNOS: refactor smp specific code and routines
> ARM: EXYNOS: refactor of mach-exynos to use chipid information
>
> arch/arm/mach-exynos/Kconfig | 1 +
> arch/arm/mach-exynos/common.h | 92 ---------
> arch/arm/mach-exynos/exynos.c | 38 ----
> arch/arm/mach-exynos/firmware.c | 100 +++++++---
> arch/arm/mach-exynos/include/mach/map.h | 21 ---
> arch/arm/mach-exynos/platsmp.c | 267 +++++++++++++++++++++------
> arch/arm/mach-exynos/pm.c | 185 ++++++++++++++++---
> arch/arm/plat-samsung/cpu.c | 14 --
> arch/arm/plat-samsung/include/plat/cpu.h | 2 -
> arch/arm/plat-samsung/include/plat/map-s5p.h | 2 -
> arch/arm64/Kconfig.platforms | 1 +
> drivers/soc/samsung/Kconfig | 5 +
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 116 ++++++++++++
> 14 files changed, 563 insertions(+), 282 deletions(-)
> delete mode 100644 arch/arm/mach-exynos/include/mach/map.h
> create mode 100644 drivers/soc/samsung/exynos-chipid.c
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [RESEND PATCH 2/2] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhong jiang @ 2016-12-16 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216123512.GF13191@arm.com>
On 2016/12/16 20:35, Will Deacon wrote:
> On Fri, Dec 16, 2016 at 05:10:05PM +0800, zhong jiang wrote:
>> On 2016/12/14 22:19, zhongjiang wrote:
>>> From: zhong jiang <zhongjiang@huawei.com>
>>>
>>> when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
>>> fuctions should not be use. therefore, we add the dependency.
>>>
>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 969ef88..694ca73 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
>>>
>>> config ARCH_WANT_HUGE_PMD_SHARE
>>> def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
>>> + depends on HUGETLB_PAGE
>>>
>>> config ARCH_HAS_CACHE_LINE_SIZE
>>> def_bool y
>> Hi,
>> I still think it is a issue. Perhaps above changelog is unclear. Further explain is as follows.
>> when hugetlb_pages is disable and arch_want_huge_pmd_share is enable, we maybe call
>> huge_pmd_sahre in hugetlbpage.c, but the function actually is not definition as it is not
>> exported. is it right ??
> The only users of ARCH_WANT_HUGE_PMD_SHARE on arm64 are:
>
> arch/arm64/mm/hugetlbpage.c: if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
yes
> mm/hugetlb.c:#ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
> mm/hugetlb.c:#else /* !CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
> mm/hugetlb.c:#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
>
> and neither of those files are compiled if !HUGETLB_PAGE.
Indeed, but The only users maybe use it if !HUGETLB_PAGE.
because include/linux/hugetlb.h can not export the reference if !HUGETLB_PAGE.
IOW, the function is not definition.
is it right ? or I miss the key point.
> Are you actually seeing a problem here?
I review the code and find the issue.
Thanks
zhongjiang
> Will
>
> .
>
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Javier Martinez Canillas @ 2016-12-16 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612161348.35917@pali>
Hello Pali,
On 12/16/2016 09:48 AM, Pali Roh?r wrote:
> On Friday 16 December 2016 13:38:34 Javier Martinez Canillas wrote:
>> Hello Pali,
>>
>> On 12/16/2016 09:32 AM, Pali Roh?r wrote:
>>> Hi!
>>>
>>> On Friday 16 December 2016 13:13:34 Javier Martinez Canillas wrote:
>>>> Hello Pali,
>>>>
>>>> On 12/16/2016 08:46 AM, Pali Roh?r wrote:
>>>>> On Thursday 15 December 2016 01:09:20 Pali Roh?r wrote:
>>>>>> On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux
>>>>>>
>>>>>> wrote:
>>>>>>> On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Roh?r wrote:
>>>>>>>> Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi
>>>>>>>> usage") broke support for setting cmdline on Nokia N900 via
>>>>>>>> CONFIG_CMDLINE.
>>>>>>>>
>>>>>>>> It is because arm code booted in DT mode parse cmdline only
>>>>>>>> via function early_init_dt_scan_chosen() and that function
>>>>>>>> does not fill variable boot_command_line when DTB does not
>>>>>>>> contain /chosen entry. It is called from function
>>>>>>>> early_init_dt_scan_nodes() in setup_machine_fdt().
>>>>>>>>
>>>>>>>> This patch fixes it by explicitly filling boot_command_line in
>>>>>>>> function setup_machine_fdt() after calling
>>>>>>>> early_init_dt_scan_nodes() in case boot_command_line still
>>>>>>>> remains empty.
>>>>>>>
>>>>>>> This looks like a hack.
>>>>>>>
>>>>>>> First, the matter of the ATAGs compatibility. The decompressor
>>>>>>> relies on there being a pre-existing /chosen node to insert the
>>>>>>> command line and other parameters into. If we've dropped it
>>>>>>> (by dropping skeleton.dtsi) then we've just regressed more
>>>>>>> than just N900 - the decompressor won't be able to merge the
>>>>>>> ATAGs into the concatenated FDT.
>>>>>>
>>>>>> Hm... I did not think about it. But right this can be broken
>>>>>> too...
>>>>>
>>>>> Tony, Javier: are you aware of above ??? problem?
>>>>>
>>>>> It looks like commit 008a2ebcd677 ("ARM: dts: omap3: Remove
>>>>> skeleton.dtsi usage") should be really reverted.
>>>>
>>>> I don't think reverting the mentioned commit is the correct fix
>>>> for your problem. We are trying to get rid of skeleton.dtsi for
>>>> many reasons, see commit commit ("3ebee5a2e141 arm64: dts: kill
>>>> skeleton.dtsi").
>>>
>>> $ git show 3ebee5a2e141
>>>
>>> * The default empty /chosen and /aliases are somewhat useless...
>>>
>>> That is not truth, they are not useless as Russell King wrote --
>>> removing them break ATAG support.
>>>
>>> (But that commit is for arm64 which probably is not using ATAGs...
>>> But I do not know. At least it is not truth for 32bit arm.)
>>>
>>>> Also, the chosen node is mentioned to be optional in the ePAPR
>>>> document and u-boot creates a chosen node if isn't found [0] so
>>>> this issue is only present in boards that don't use u-boot like
>>>> the N900/N950/N9 phones.
>>>
>>> Linux arm decompressor does not propagate ATAGs when /chosen is
>>> missing. Sorry, but if for Linux /chosen is required (and without
>>> it is broken!) then some ePARP document does not apply there.
>>> Either Linux code needs to be fixed (so /chosen will be really
>>> only optional) or /chosen stay in Linux required. There is no
>>> other option.
>>>
>>> And I hope that U-boot is not the only one bootloader which Linux
>>> kernel supports. I thought that I can use *any* bootloader to boot
>>> Linux kernel not just U-Boot which is doing some magic...
>>>
>>> With this step you are basically going to break booting Linux
>>> kernel with all others bootloaders... And personally I really
>>> dislike this idea.
>>>
>>>> So if NOLO doesn't do the same than u-boot and the kernel expects
>>>> a chosen node, I suggest to add an empty chosen node in the
>>>> omap3-n900.dts and omap3-n950-n9.dtsi device tree source files.
>>>
>>> That would fix a problem for N900, N950 and N9. But not for all
>>> other ARM devices which bootloader pass some ATAGs.
>>>
>>> IIRC rule of kernel is not to break compatibility and that commit
>>> 008a2ebcd677 really did it.
>>>
>>> Note: I'm not saying if 008a2ebcd677 is good or bad. I'm just
>>> saying that it cause problems which need to be properly fixed. And
>>> if fixing them is harder and will take more time, then correct
>>> option is to revert 008a2ebcd677 due to breaking support for more
>>> devices.
>>
>> If you think that others boards may have the same issue, then you
>> could add an empty chosen node to omap3.dtsi. As I said I think that
>> in practice this will only be needed for the machines using NOLO but
>> you are right that in theory you could boot them using other
>> bootloaders and having an empty node doesn't cause any harm anyway.
>
> Should not be it part of any arm board? IIRC ATAG support is (or was)
> not omap3 specified.
>
Yes, but you were talking about commit 008a2ebcd677 which only removed
skeleton.dtsi usage for OMAP3 boards. The same can be done for other
SoCs in its top level dtsi for the SoC family of course.
>>>> [0]:
>>>> http://git.denx.de/?p=u-boot.git;a=blob;f=common/fdt_support.c;h=c
>>>> 9f 7019e38e8de1469f506cdd57353fd27d8e134;hb=HEAD#l226
>>>>
>>>> Best regards,
>>
>> Best regards,
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs
From: Pali Rohár @ 2016-12-16 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c56e769-76be-295e-b655-8431dde35370@osg.samsung.com>
On Friday 16 December 2016 13:38:34 Javier Martinez Canillas wrote:
> Hello Pali,
>
> On 12/16/2016 09:32 AM, Pali Roh?r wrote:
> > Hi!
> >
> > On Friday 16 December 2016 13:13:34 Javier Martinez Canillas wrote:
> >> Hello Pali,
> >>
> >> On 12/16/2016 08:46 AM, Pali Roh?r wrote:
> >>> On Thursday 15 December 2016 01:09:20 Pali Roh?r wrote:
> >>>> On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux
> >>>>
> >>>> wrote:
> >>>>> On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Roh?r wrote:
> >>>>>> Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi
> >>>>>> usage") broke support for setting cmdline on Nokia N900 via
> >>>>>> CONFIG_CMDLINE.
> >>>>>>
> >>>>>> It is because arm code booted in DT mode parse cmdline only
> >>>>>> via function early_init_dt_scan_chosen() and that function
> >>>>>> does not fill variable boot_command_line when DTB does not
> >>>>>> contain /chosen entry. It is called from function
> >>>>>> early_init_dt_scan_nodes() in setup_machine_fdt().
> >>>>>>
> >>>>>> This patch fixes it by explicitly filling boot_command_line in
> >>>>>> function setup_machine_fdt() after calling
> >>>>>> early_init_dt_scan_nodes() in case boot_command_line still
> >>>>>> remains empty.
> >>>>>
> >>>>> This looks like a hack.
> >>>>>
> >>>>> First, the matter of the ATAGs compatibility. The decompressor
> >>>>> relies on there being a pre-existing /chosen node to insert the
> >>>>> command line and other parameters into. If we've dropped it
> >>>>> (by dropping skeleton.dtsi) then we've just regressed more
> >>>>> than just N900 - the decompressor won't be able to merge the
> >>>>> ATAGs into the concatenated FDT.
> >>>>
> >>>> Hm... I did not think about it. But right this can be broken
> >>>> too...
> >>>
> >>> Tony, Javier: are you aware of above ??? problem?
> >>>
> >>> It looks like commit 008a2ebcd677 ("ARM: dts: omap3: Remove
> >>> skeleton.dtsi usage") should be really reverted.
> >>
> >> I don't think reverting the mentioned commit is the correct fix
> >> for your problem. We are trying to get rid of skeleton.dtsi for
> >> many reasons, see commit commit ("3ebee5a2e141 arm64: dts: kill
> >> skeleton.dtsi").
> >
> > $ git show 3ebee5a2e141
> >
> > * The default empty /chosen and /aliases are somewhat useless...
> >
> > That is not truth, they are not useless as Russell King wrote --
> > removing them break ATAG support.
> >
> > (But that commit is for arm64 which probably is not using ATAGs...
> > But I do not know. At least it is not truth for 32bit arm.)
> >
> >> Also, the chosen node is mentioned to be optional in the ePAPR
> >> document and u-boot creates a chosen node if isn't found [0] so
> >> this issue is only present in boards that don't use u-boot like
> >> the N900/N950/N9 phones.
> >
> > Linux arm decompressor does not propagate ATAGs when /chosen is
> > missing. Sorry, but if for Linux /chosen is required (and without
> > it is broken!) then some ePARP document does not apply there.
> > Either Linux code needs to be fixed (so /chosen will be really
> > only optional) or /chosen stay in Linux required. There is no
> > other option.
> >
> > And I hope that U-boot is not the only one bootloader which Linux
> > kernel supports. I thought that I can use *any* bootloader to boot
> > Linux kernel not just U-Boot which is doing some magic...
> >
> > With this step you are basically going to break booting Linux
> > kernel with all others bootloaders... And personally I really
> > dislike this idea.
> >
> >> So if NOLO doesn't do the same than u-boot and the kernel expects
> >> a chosen node, I suggest to add an empty chosen node in the
> >> omap3-n900.dts and omap3-n950-n9.dtsi device tree source files.
> >
> > That would fix a problem for N900, N950 and N9. But not for all
> > other ARM devices which bootloader pass some ATAGs.
> >
> > IIRC rule of kernel is not to break compatibility and that commit
> > 008a2ebcd677 really did it.
> >
> > Note: I'm not saying if 008a2ebcd677 is good or bad. I'm just
> > saying that it cause problems which need to be properly fixed. And
> > if fixing them is harder and will take more time, then correct
> > option is to revert 008a2ebcd677 due to breaking support for more
> > devices.
>
> If you think that others boards may have the same issue, then you
> could add an empty chosen node to omap3.dtsi. As I said I think that
> in practice this will only be needed for the machines using NOLO but
> you are right that in theory you could boot them using other
> bootloaders and having an empty node doesn't cause any harm anyway.
Should not be it part of any arm board? IIRC ATAG support is (or was)
not omap3 specified.
> >> [0]:
> >> http://git.denx.de/?p=u-boot.git;a=blob;f=common/fdt_support.c;h=c
> >> 9f 7019e38e8de1469f506cdd57353fd27d8e134;hb=HEAD#l226
> >>
> >> Best regards,
>
> Best regards,
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161216/debc8ab2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-16 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213233658.atGuNCNY@smtp1h.mail.yandex.net>
On Fri, Dec 09, 2016 at 07:49:00PM +0800, Icenowy Zheng wrote:
>
> 2016?12?9? ??4:07? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >
> > On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
> > > Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
> > > has a dedicated enable pin (PL8 in the reference design).
> > >
> > > Enable the pin in the same way as the WLAN enable pins.
> > >
> > > Tested on an A33 Q8 tablet with RTL8703AS.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > > ---
> > >
> > > This patch should be coupled with the uart1 node patch I send before:
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
> > >
> > > For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
> > > https://github.com/lwfinger/rtl8723bs_bt
> > >
> > >? arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
> > >? 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > index c676940..4aeb5bb 100644
> > > --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > @@ -88,7 +88,7 @@
> > >?
> > >? &r_pio {
> > >? wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
> > > - pins = "PL6", "PL7", "PL11";
> > > + pins = "PL6", "PL7", "PL8", "PL11";
> > >? function = "gpio_in";
> > >? bias-pull-up;
> > >? };
> >
> > There's several things wrong here. The first one is that you rely
> > solely on the pinctrl state to maintain a reset line. This is very
> > fragile (especially since the GPIO pinctrl state are likely to go away
> > at some point), but it also means that if your driver wants to recover
> > from that situation at some point, it won't work.
> >
> > The other one is that the bluetooth and wifi chips are two devices in
> > linux, and you assign that pin to the wrong device (wifi).
> >
> > rfkill-gpio is made just for that, so please use it.
>
> The GPIO is not for the radio, but for the full Bluetooth part.
I know.
> If it's set to 0, then the bluetooth part will reset, and the
> hciattach will fail.
Both rfkill-gpio and rfkill-regulator will shutdown when called
(either by poking the reset pin or shutting down the regulator), so
that definitely seems like an expected behavior to put the device in
reset.
> The BSP uses this as a rfkill, and the result is that the bluetooth
> on/off switch do not work properly.
Then rfkill needs fixing, but working around it by hoping that the
core will probe an entirely different device, and enforcing a default
that the rest of the kernel might or might not change is both fragile
and wrong.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161216/7af246ff/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox