* Re: [PATCH v9 02/16] clk: qcom: Move all sdcc rcgs to use clk_rcg2_floor_ops
From: Stephen Boyd @ 2016-11-23 19:00 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, andy.gross, shawn.lin,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd,
david.griego, stummala, venkatg, rnayak, pramod.gurav, jeremymc
In-Reply-To: <1479710246-26676-3-git-send-email-riteshh@codeaurora.org>
On 11/21, Ritesh Harjani wrote:
> From: Rajendra Nayak <rnayak@codeaurora.org>
>
> The sdcc driver for msm8996/msm8916/msm8974/msm8994 and apq8084
> expects a clk_set_rate() on the sdcc rcg clk to set
> a floor value of supported clk rate closest to the requested
> rate, by looking up the frequency table.
> So move all the sdcc rcgs on all these platforms to use the
> newly introduced clk_rcg2_floor_ops
>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v9 01/16] clk: qcom: Add rcg ops to return floor value closest to the requested rate
From: Stephen Boyd @ 2016-11-23 19:00 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
alex.lemberg-XdAiOPVOjttBDgjK7y7TUQ,
mateusz.nowak-ral2JQCrhuEAvxtiuMwx3w,
Yuliy.Izrailov-XdAiOPVOjttBDgjK7y7TUQ,
asutoshd-sgV2jX0FEOL9JmXXK+q4OQ,
david.griego-QSEj5FYQhm4dnm+yROfE0A,
stummala-sgV2jX0FEOL9JmXXK+q4OQ, venkatg-sgV2jX0FEOL9JmXXK+q4OQ,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
pramod.gurav-QSEj5FYQhm4dnm+yROfE0A,
jeremymc-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1479710246-26676-2-git-send-email-riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 11/21, Ritesh Harjani wrote:
> From: Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> The default behaviour with clk_rcg2_ops is for the
> clk_round_rate()/clk_set_rate() to return/set a ceil clock
> rate closest to the requested rate by looking up the corresponding
> frequency table.
> However, we do have some instances (mainly sdcc on various platforms)
> of clients expecting a clk_set_rate() to set a floor value instead.
> Add a new clk_rcg2_floor_ops to handle this for such specific
> rcg instances
>
> Signed-off-by: Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ALSA SoC MAX98927 driver - Initial release
From: kbuild test robot @ 2016-11-23 18:56 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all-JC7UmRfGjtg, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
broonie-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
arnd-r2nGTMty4D4, michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
yesanishhere-Re5JQEeQqe8AvxtiuMwx3w,
jacob-EZCvousvhKUZux3j3Bed6dkegs52MxvZ,
Damien.Horsley-1AXoQHu6uovQT0dZR+AlfA,
bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
petr-Qh/3xLP0EvwAvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
nh6z-fFIq/eER6g8, ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]
Hi Ryan,
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ryan-Lee/ALSA-SoC-MAX98927-driver-Initial-release/20161124-004840
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
sound/soc/codecs/max98927.c:755:2: error: unknown field 'dapm_routes' specified in initializer
>> sound/soc/codecs/max98927.c:755:2: warning: initialization from incompatible pointer type [enabled by default]
sound/soc/codecs/max98927.c:755:2: warning: (near initialization for 'soc_codec_dev_max98927.remove') [enabled by default]
sound/soc/codecs/max98927.c:756:2: error: unknown field 'num_dapm_routes' specified in initializer
>> sound/soc/codecs/max98927.c:756:21: warning: initialization makes pointer from integer without a cast [enabled by default]
sound/soc/codecs/max98927.c:756:21: warning: (near initialization for 'soc_codec_dev_max98927.suspend') [enabled by default]
sound/soc/codecs/max98927.c:757:2: error: unknown field 'dapm_widgets' specified in initializer
sound/soc/codecs/max98927.c:757:2: warning: initialization from incompatible pointer type [enabled by default]
sound/soc/codecs/max98927.c:757:2: warning: (near initialization for 'soc_codec_dev_max98927.resume') [enabled by default]
sound/soc/codecs/max98927.c:758:2: error: unknown field 'num_dapm_widgets' specified in initializer
sound/soc/codecs/max98927.c:758:22: warning: missing braces around initializer [-Wmissing-braces]
sound/soc/codecs/max98927.c:758:22: warning: (near initialization for 'soc_codec_dev_max98927.component_driver') [-Wmissing-braces]
sound/soc/codecs/max98927.c:758:22: warning: initialization makes pointer from integer without a cast [enabled by default]
sound/soc/codecs/max98927.c:758:22: warning: (near initialization for 'soc_codec_dev_max98927.component_driver.name') [enabled by default]
sound/soc/codecs/max98927.c:759:2: error: unknown field 'controls' specified in initializer
sound/soc/codecs/max98927.c:759:2: warning: initialization from incompatible pointer type [enabled by default]
sound/soc/codecs/max98927.c:759:2: warning: (near initialization for 'soc_codec_dev_max98927.set_sysclk') [enabled by default]
sound/soc/codecs/max98927.c:760:2: error: unknown field 'num_controls' specified in initializer
sound/soc/codecs/max98927.c:760:18: warning: initialization makes pointer from integer without a cast [enabled by default]
sound/soc/codecs/max98927.c:760:18: warning: (near initialization for 'soc_codec_dev_max98927.set_pll') [enabled by default]
vim +755 sound/soc/codecs/max98927.c
749
750 return ret;
751 }
752
753 static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
754 .probe = max98927_probe,
> 755 .dapm_routes = max98927_audio_map,
> 756 .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
757 .dapm_widgets = max98927_dapm_widgets,
758 .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
759 .controls = max98927_snd_controls,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 46522 bytes --]
^ permalink raw reply
* [PATCH v4 2/2] DW DMAC: add multi-block property to device tree
From: Eugeniy Paltsev @ 2016-11-23 18:37 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, arnd, vinod.koul, linux-kernel,
robh+dt, dmaengine, andriy.shevchenko, Eugeniy Paltsev
In-Reply-To: <1479926268-29050-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Also:
Update DT documentation.
Update existing platform data.
Documentation/devicetree/bindings/dma/snps-dma.txt | 3 +++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +++++
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 4 ++--
5 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..0c6256d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,9 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- multi-block: Multi block transfers supported by hardware per AHB master.
+ Array property with one cell per master. 0 (default): not supported,
+ 1: supported.
Example:
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..e5adf5d 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = !pdata->multi_block[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index aa7a5c1..b262fd3 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -152,6 +152,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "multi-block", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->multi_block[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
index f607946..58cbb30 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -157,12 +157,12 @@ static int byt_serial_setup(struct lpss8250 *lpss, struct uart_port *port)
static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
.nr_channels = 2,
.is_private = true,
- .is_nollp = true,
.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
.chan_priority = CHAN_PRIORITY_ASCENDING,
.block_size = 4095,
.nr_masters = 1,
.data_width = {4},
+ .multi_block = {0},
};
static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..0773bb4 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @multi_block: Multi block transfers supported by hardware per AHB master.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR_MASTERS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH v4 1/2] DW DMAC: enable memory-to-memory transfers support
From: Eugeniy Paltsev @ 2016-11-23 18:37 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eugeniy Paltsev
In-Reply-To: <1479926268-29050-1-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.
Acked-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
drivers/dma/dw/platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ /*
+ * All known devices, which use DT for configuration, support
+ * memory-to-memory transfers. So enable it by default.
+ */
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/2] DW DMAC: update device tree
From: Eugeniy Paltsev @ 2016-11-23 18:37 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, arnd, vinod.koul, linux-kernel,
robh+dt, dmaengine, andriy.shevchenko, Eugeniy Paltsev
It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
Changes for v4:
* Fix setting inverted value to "dwc->nollp". My fault - I
tested with wrong DTS, so DMAC was configured from autoconfig
instead of device tree. Pointed by Andy Shevchenko.
* Update "multi-block" diescription in documentation to be more
clear. Pointed by Arnd Bergmann.
Changes for v3:
* Update existing platform data.
We don't need to update existing DTS because default logic
wasn't change: we don't set "is_nollp" if we read
configuration from DT before. And we don't set it now if
"multi-block" property doesn't exist in DTS.
Changes for v2:
* I thought about is_memcpy DT property: all known devices, which
use DT for configuration, support memory-to-memory transfers.
So we don't need to read it from DT. So enable it by default,
if we read configuration from DT.
* Use "multi-block" instead of "hw-llp" name to be more clear.
* Move adding DT property and adding documentation for this
property to one patch.
Eugeniy Paltsev (2):
DW DMAC: enable memory-to-memory transfers support
DW DMAC: add multi-block property to device tree
Documentation/devicetree/bindings/dma/snps-dma.txt | 3 +++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 11 +++++++++++
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 4 ++--
5 files changed, 18 insertions(+), 4 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-23 18:36 UTC (permalink / raw)
To: Andrew Lunn, tomas.hlavacek-x+rMaJPWets
Cc: Mark Rutland, marex-ynQEQJNshbs, Jason Cooper,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <20161123145916.GL14947-g2DYL2Zd6BY@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]
Hello Andrew,
On 11/23/2016 03:59 PM, Andrew Lunn wrote:
>>> CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
no this is not the problem. When booting the OpenWRT based system I can
communicate with the device via the switch. (Didn't test deeply, but my
Laptop got a dhcp lease from the Turris Omnia and I can ping it.) But
this convinces me, that the hardware is good enough.
If you have any ideas what I can try to make the switch work or help to
diagnose the problem, just let me know.
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Matthias Brugger @ 2016-11-23 18:32 UTC (permalink / raw)
To: Hongzhou Yang, chunfeng yun
Cc: Linus Walleij, Maoguang Meng, Yingjoe Chen, Greg Kroah-Hartman,
Felipe Balbi, Mathias Nyman, Alan Stern, Rob Herring,
Mark Rutland, Ian Campbell, Sergei Shtylyov, Pawel Moll,
Kumar Gala, Sascha Hauer, Biao Huang, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel
In-Reply-To: <1463021701.25171.5.camel@mussux00>
Hi Hongzhou,
On 12/05/16 04:55, Hongzhou Yang wrote:
> On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote:
>> On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote:
>>> Hi,
>>>
>>> On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote:
>>>> On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote:
>>>>> On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun
>>>>> <chunfeng.yun@mediatek.com> wrote:
>>>>>
>>>>>> the default mode of GPIO16 pin is gpio, when set EINT16 to
>>>>>> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
>>>>>> fixed when set its default mode as usb iddig.
>>>>>>
>>>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>>>>
>>>>
>>>> Chunfeng, GPIO16 can be used as EINT16 mode, but the pinmux should be 0.
>>>> If you want to set its default mode to iddig, you should set it in dts.
>>>>
>>> I set it in DTS, but it didn't work, because when usb driver requested
>>> IRQ, pinmux was switched back to default mode set by
>>> MTK_EINT_FUNCTION().
>>>
>>
>> After confirmed, there are something wrong with data sheet and pinmux
>> table, and GPIO16 can only receive interrupt by mode 1. So
>>
>> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
>>
>
> Linus,
>
> We find there are some other pins still have the same problem, so please
> hold on it. Sorry for so much noise.
>
Did you made any progress on this? I didn't see any patch on the mailing
list.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:23 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Kevin Hilman, Michael Turquette,
Rob Herring, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Sudeep Holla
In-Reply-To: <5835DC2D.5080606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/23/16 10:13, Frank Rowand wrote:
> On 11/22/16 21:55, Sekhar Nori wrote:
>> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>>> Please note that the compatible property might contain several strings, not just
>>> a single string.
>>
>> So I guess the best thing to do is to use
>> of_property_read_string_index() and print the sting at index 0.
>>
>> Thanks,
>> Sekhar
>
> If you want to print just one compatible value, you could use that method.
>
> To give all of the information needed to understand the problem, the error
> message would need to include all of the strings contained in the compatible
> property and all of the .board values in the da8xx_ddrctl_board_confs[] array
> (currently only one entry, but coded to allow additional entries in the
> future).
>
> It is hard to justify an error message that complex.
>
> I would just print an error that no match was found.
>
> -Frank
I just needed to read some more emails. I see this approach was taken
in the "[PATCH v4 0/2] da8xx: fix section mismatch in new drivers"
series.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] fix platform_no_drv_owner.cocci warnings
From: kbuild test robot @ 2016-11-23 18:13 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all, lgirdwood, broonie, robh+dt, mark.rutland, perex,
tiwai, arnd, michael, oder_chiou, yesanishhere, jacob,
Damien.Horsley, bardliao, kuninori.morimoto.gx, petr, lars, nh6z,
ryans.lee, alsa-devel, devicetree, linux-kernel
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee@maximintegrated.com>
sound/soc/codecs/max98927.c:941:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Ryan Lee <RyanS.Lee@maximintegrated.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
max98927.c | 1 -
1 file changed, 1 deletion(-)
--- a/sound/soc/codecs/max98927.c
+++ b/sound/soc/codecs/max98927.c
@@ -938,7 +938,6 @@ MODULE_DEVICE_TABLE(of, max98927_of_matc
static struct i2c_driver max98927_i2c_driver = {
.driver = {
.name = "max98927",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(max98927_of_match),
.pm = NULL,
},
^ permalink raw reply
* Re: [PATCH] ALSA SoC MAX98927 driver - Initial release
From: kbuild test robot @ 2016-11-23 18:13 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all-JC7UmRfGjtg, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
broonie-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
arnd-r2nGTMty4D4, michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
yesanishhere-Re5JQEeQqe8AvxtiuMwx3w,
jacob-EZCvousvhKUZux3j3Bed6dkegs52MxvZ,
Damien.Horsley-1AXoQHu6uovQT0dZR+AlfA,
bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
petr-Qh/3xLP0EvwAvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
nh6z-fFIq/eER6g8, ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
Hi Ryan,
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ryan-Lee/ALSA-SoC-MAX98927-driver-Initial-release/20161124-004840
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
coccinelle warnings: (new ones prefixed by >>)
>> sound/soc/codecs/max98927.c:941:3-8: No need to set .owner here. The core will do it.
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:13 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Kevin Hilman, Michael Turquette,
Rob Herring, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Sudeep Holla
In-Reply-To: <b668871c-2b54-0a2f-0d68-afaa50e17e63-l0cyMroinI0@public.gmane.org>
On 11/22/16 21:55, Sekhar Nori wrote:
> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>> Please note that the compatible property might contain several strings, not just
>> a single string.
>
> So I guess the best thing to do is to use
> of_property_read_string_index() and print the sting at index 0.
>
> Thanks,
> Sekhar
If you want to print just one compatible value, you could use that method.
To give all of the information needed to understand the problem, the error
message would need to include all of the strings contained in the compatible
property and all of the .board values in the da8xx_ddrctl_board_confs[] array
(currently only one entry, but coded to allow additional entries in the
future).
It is hard to justify an error message that complex.
I would just print an error that no match was found.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv7 4/5] USB: ohci: da8xx: Add devicetree bindings
From: Axel Haslam @ 2016-11-23 18:06 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, david-nq/r/kbU++upp/zk7JDF2g,
ptitiano-rdvid1DuHRBWk0Htik3J/w
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161123180649.6438-1-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
This patch documents the device tree bindings required for
the ohci controller found in TI da8xx family of SoC's
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/usb/ohci-da8xx.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
new file mode 100644
index 0000000..2dc8f67
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
@@ -0,0 +1,23 @@
+DA8XX USB OHCI controller
+
+Required properties:
+
+ - compatible: Should be "ti,da830-ohci"
+ - reg: Should contain one register range i.e. start and length
+ - interrupts: Description of the interrupt line
+ - phys: Phandle for the PHY device
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+ - vbus-supply: phandle of regulator that controls vbus power / over-current
+
+Example:
+
+ohci: usb@0225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ vbus-supply = <®_usb_ohci>;
+};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ALSA SoC MAX98927 driver - Initial release
From: kbuild test robot @ 2016-11-23 17:51 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all, lgirdwood, broonie, robh+dt, mark.rutland, perex,
tiwai, arnd, michael, oder_chiou, yesanishhere, jacob,
Damien.Horsley, bardliao, kuninori.morimoto.gx, petr, lars, nh6z,
ryans.lee, alsa-devel, devicetree, linux-kernel
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee@maximintegrated.com>
[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]
Hi Ryan,
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ryan-Lee/ALSA-SoC-MAX98927-driver-Initial-release/20161124-004840
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> sound/soc/codecs/max98927.c:755:2: error: unknown field 'dapm_routes' specified in initializer
.dapm_routes = max98927_audio_map,
^
>> sound/soc/codecs/max98927.c:755:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.dapm_routes = max98927_audio_map,
^~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:755:17: note: (near initialization for 'soc_codec_dev_max98927.remove')
>> sound/soc/codecs/max98927.c:756:2: error: unknown field 'num_dapm_routes' specified in initializer
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> sound/soc/codecs/max98927.c:756:21: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.suspend')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> sound/soc/codecs/max98927.c:756:21: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:757:2: error: unknown field 'dapm_widgets' specified in initializer
.dapm_widgets = max98927_dapm_widgets,
^
sound/soc/codecs/max98927.c:757:18: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.dapm_widgets = max98927_dapm_widgets,
^~~~~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:757:18: note: (near initialization for 'soc_codec_dev_max98927.resume')
>> sound/soc/codecs/max98927.c:758:2: error: unknown field 'num_dapm_widgets' specified in initializer
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:758:22: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.component_driver.name')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:758:22: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:759:2: error: unknown field 'controls' specified in initializer
.controls = max98927_snd_controls,
^
sound/soc/codecs/max98927.c:759:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.controls = max98927_snd_controls,
^~~~~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:759:14: note: (near initialization for 'soc_codec_dev_max98927.set_sysclk')
>> sound/soc/codecs/max98927.c:760:2: error: unknown field 'num_controls' specified in initializer
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:760:18: note: in expansion of macro 'ARRAY_SIZE'
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.set_pll')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:760:18: note: in expansion of macro 'ARRAY_SIZE'
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:753:67: warning: missing braces around initializer [-Wmissing-braces]
static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
^
sound/soc/codecs/max98927.c:753:67: note: (near initialization for 'soc_codec_dev_max98927')
cc1: some warnings being treated as errors
vim +/dapm_routes +755 sound/soc/codecs/max98927.c
747
748 max98927_handle_pdata(codec);
749
750 return ret;
751 }
752
> 753 static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
754 .probe = max98927_probe,
> 755 .dapm_routes = max98927_audio_map,
> 756 .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
> 757 .dapm_widgets = max98927_dapm_widgets,
> 758 .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
> 759 .controls = max98927_snd_controls,
> 760 .num_controls = ARRAY_SIZE(max98927_snd_controls),
761 };
762
763 static const struct regmap_config max98927_regmap = {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56946 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: enable hs400 mode for eMMC for TM2
From: Krzysztof Kozlowski @ 2016-11-23 17:29 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, kgene-DgEjT+Ai2ygdnm+yROfE0A,
krzk-DgEjT+Ai2ygdnm+yROfE0A, cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <20161123074334.27784-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Nov 23, 2016 at 04:43:34PM +0900, Jaehoon Chung wrote:
> TM2 can support the HS400 mode, but eMMC is working as the lowest mode.
> This patch added the properties for HS400 and other modes.
>
> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
Thanks, applied.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] gpio: axp209: add pinctrl support
From: kbuild test robot @ 2016-11-23 17:21 UTC (permalink / raw)
Cc: kbuild-all, linus.walleij, gnurou, robh+dt, mark.rutland, wens,
Quentin Schulz, linux-gpio, devicetree, linux-kernel,
thomas.petazzoni
In-Reply-To: <20161123132749.11666-3-quentin.schulz@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]
Hi Quentin,
[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-support-for-AXP209-GPIOs-functions/20161124-003102
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-i0-201647 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_get_direction':
>> drivers/gpio/gpio-axp209.c:131:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_set':
drivers/gpio/gpio-axp209.c:158:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set':
drivers/gpio/gpio-axp209.c:183:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: At top level:
drivers/gpio/gpio-axp209.c:348:21: error: 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function)
.dt_node_to_map = pinconf_generic_dt_node_to_map_group,
^
drivers/gpio/gpio-axp209.c:349:18: error: 'pinconf_generic_dt_free_map' undeclared here (not in a function)
.dt_free_map = pinconf_generic_dt_free_map,
^
vim +131 drivers/gpio/gpio-axp209.c
115 static int axp20x_gpio_get(struct gpio_chip *chip, unsigned offset)
116 {
117 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
118 unsigned int val;
119 int ret;
120
121 ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
122 if (ret)
123 return ret;
124
125 return !!(val & BIT(offset + 4));
126 }
127
128 static int axp20x_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
129 {
130 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 131 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
132 unsigned int val;
133 int ret;
134
135 ret = regmap_read(pctl->regmap, pin_reg, &val);
136 if (ret)
137 return ret;
138
139 /*
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33990 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: exynos: remove the cd-gpios property for eMMC of odroid-xu3/4
From: Krzysztof Kozlowski @ 2016-11-23 17:20 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Andrzej Hajda, Krzysztof Kozlowski, linux-samsung-soc,
linux-kernel, devicetree, kgene, cw00.choi, robh+dt, mark.rutland,
catalin.marinas, will.deacon, m.szyprowski, jy0922.shim
In-Reply-To: <00c4e163-98ed-fcc5-2248-22c697967032@samsung.com>
On Tue, Nov 22, 2016 at 05:19:30PM +0900, Jaehoon Chung wrote:
> On 11/22/2016 04:51 PM, Andrzej Hajda wrote:
> > On 22.11.2016 02:24, Jaehoon Chung wrote:
> >> On 11/22/2016 02:06 AM, Krzysztof Kozlowski wrote:
> >>> On Mon, Nov 21, 2016 at 04:10:32PM +0900, Jaehoon Chung wrote:
> >>>> Odroid-xu3/4 didn't need to use the cd-gpios for detecting card.
> >>>> Because Host controller has the CDETECT register through SDx_CDN line.
> >>>> Host controller can know whether card is inserted or not with this
> >>>> register.
> >>>>
> >>>> When i have checked the Odroid-xu3/4, they are using CDETECT register.
> >>>> (Not using exteranl cd-gpio.)
> >>> Makes sense. Just one question: the sd0_cd pinctrl setting should stay,
> >>> right?
Thanks, applied with removal of Fixes tag because commit description did
not mention any issue, error or wrong behavior to fix.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: exynos: specify snps,dwmac in compatible string for gmac
From: Krzysztof Kozlowski @ 2016-11-23 17:19 UTC (permalink / raw)
To: Niklas Cassel
Cc: Rob Herring, Mark Rutland, Russell King, Kukjin Kim,
Krzysztof Kozlowski, Javier Martinez Canillas, Niklas Cassel,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel
In-Reply-To: <1479911091-19812-1-git-send-email-niklass@axis.com>
On Wed, Nov 23, 2016 at 03:24:51PM +0100, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> devicetree binding for stmmac states:
> - compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
> For backwards compatibility: "st,spear600-gmac" is also supported.
>
> No functional change intended.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> ---
> arch/arm/boot/dts/exynos5440.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-23 17:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161123080350.fstwdfndghk7c5xx@lukather>
On Wed, 23 Nov 2016 09:03:50 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > and uart pins along power in one connector and are found on most,
> > if not all, Olimex boards.
> > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > those two connectors.
> >
> > Signed-off-by: Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
>
> Fixed the indentation of the spi pinctrl cells, and applied.
>
> Please note that I'm note planning to send any new pull request, so
> this will likely end up in 4.11.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Sorry about the indentation, I'll be more carefull next time.
Thank you.
--
Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org> <manu-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] gpio: axp209: add pinctrl support
From: kbuild test robot @ 2016-11-23 17:13 UTC (permalink / raw)
Cc: kbuild-all, linus.walleij, gnurou, robh+dt, mark.rutland, wens,
Quentin Schulz, linux-gpio, devicetree, linux-kernel,
thomas.petazzoni
In-Reply-To: <20161123132749.11666-3-quentin.schulz@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 17845 bytes --]
Hi Quentin,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Quentin-Schulz/add-support-for-AXP209-GPIOs-functions/20161124-003102
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: i386-randconfig-i0-201647 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> drivers/gpio/gpio-axp209.c:60:27: error: field 'pin' has incomplete type
struct pinctrl_pin_desc pin;
^
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(0, "GPIO0", (void *)AXP20X_GPIO0_CTRL),
^
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(1, "GPIO1", (void *)AXP20X_GPIO1_CTRL),
^
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(2, "GPIO2", (void *)AXP20X_GPIO2_CTRL),
^
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_get_direction':
>> drivers/gpio/gpio-axp209.c:131:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_set':
drivers/gpio/gpio-axp209.c:158:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_input':
>> drivers/gpio/gpio-axp209.c:168:2: error: implicit declaration of function 'pinctrl_gpio_direction_input' [-Werror=implicit-function-declaration]
return pinctrl_gpio_direction_input(chip->base + offset);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set':
>> drivers/gpio/gpio-axp209.c:182:9: error: implicit declaration of function 'pinctrl_dev_get_drvdata' [-Werror=implicit-function-declaration]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
>> drivers/gpio/gpio-axp209.c:182:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c:183:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_cnt':
drivers/gpio/gpio-axp209.c:191:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_name':
drivers/gpio/gpio-axp209.c:199:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_groups':
drivers/gpio/gpio-axp209.c:209:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pinctrl_desc_find_func_by_name':
>> drivers/gpio/gpio-axp209.c:228:23: error: request for member 'name' in something not a structure or union
if (!strcmp(pin->pin.name, group)) {
^
>> drivers/gpio/gpio-axp209.c:228:3: warning: passing argument 1 of 'strcmp' from incompatible pointer type [enabled by default]
if (!strcmp(pin->pin.name, group)) {
^
In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/processor.h:17,
from include/linux/mutex.h:19,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from drivers/gpio/gpio-axp209.c:14:
arch/x86/include/asm/string_32.h:21:12: note: expected 'const char *' but argument is of type 'const struct axp20x_desc_pin *'
extern int strcmp(const char *cs, const char *ct);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set_mux':
drivers/gpio/gpio-axp209.c:253:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pctl_desc_find_func_by_pin':
>> drivers/gpio/gpio-axp209.c:276:15: error: request for member 'number' in something not a structure or union
if (pin->pin.number == offset) {
^
>> drivers/gpio/gpio-axp209.c:276:23: warning: comparison between pointer and integer [enabled by default]
if (pin->pin.number == offset) {
^
drivers/gpio/gpio-axp209.c: At top level:
>> drivers/gpio/gpio-axp209.c:293:7: warning: 'struct pinctrl_gpio_range' declared inside parameter list [enabled by default]
unsigned int offset, bool input)
^
>> drivers/gpio/gpio-axp209.c:293:7: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_gpio_set_direction':
drivers/gpio/gpio-axp209.c:295:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: At top level:
>> drivers/gpio/gpio-axp209.c:311:21: error: variable 'axp20x_pmx_ops' has initializer but incomplete type
static const struct pinmux_ops axp20x_pmx_ops = {
^
>> drivers/gpio/gpio-axp209.c:312:2: error: unknown field 'get_functions_count' specified in initializer
.get_functions_count = axp20x_pmx_func_cnt,
^
>> drivers/gpio/gpio-axp209.c:312:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:312:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:313:2: error: unknown field 'get_function_name' specified in initializer
.get_function_name = axp20x_pmx_func_name,
^
drivers/gpio/gpio-axp209.c:313:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:313:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:314:2: error: unknown field 'get_function_groups' specified in initializer
.get_function_groups = axp20x_pmx_func_groups,
^
drivers/gpio/gpio-axp209.c:314:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:314:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:315:2: error: unknown field 'set_mux' specified in initializer
.set_mux = axp20x_pmx_set_mux,
^
drivers/gpio/gpio-axp209.c:315:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:315:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
vim +/pin +60 drivers/gpio/gpio-axp209.c
8 * under the terms of the GNU General Public License as published by the
9 * Free Software Foundation; either version 2 of the License, or (at your
10 * option) any later version.
11 */
12
13 #include <linux/bitops.h>
> 14 #include <linux/device.h>
15 #include <linux/gpio/driver.h>
16 #include <linux/init.h>
17 #include <linux/interrupt.h>
18 #include <linux/kernel.h>
19 #include <linux/mfd/axp20x.h>
20 #include <linux/module.h>
21 #include <linux/of.h>
22 #include <linux/platform_device.h>
23 #include <linux/regmap.h>
24 #include <linux/slab.h>
25 #include <linux/pinctrl/pinctrl.h>
26 #include <linux/pinctrl/pinmux.h>
27 #include <linux/pinctrl/pinconf-generic.h>
28
29 #define AXP20X_GPIO_FUNCTIONS 0x7
30 #define AXP20X_GPIO_FUNCTION_OUT_LOW 0
31 #define AXP20X_GPIO_FUNCTION_OUT_HIGH 1
32 #define AXP20X_GPIO_FUNCTION_INPUT 2
33
34 #define AXP20X_PINCTRL_PIN(_pin_num, _pin, _regs) \
35 { \
36 .number = _pin_num, \
37 .name = _pin, \
38 .drv_data = _regs, \
39 }
40
41 #define AXP20X_PIN(_pin, ...) \
42 { \
43 .pin = _pin, \
44 .functions = (struct axp20x_desc_function[]) { \
45 __VA_ARGS__, { } }, \
46 }
47
48 #define AXP20X_FUNCTION(_val, _name) \
49 { \
50 .name = _name, \
51 .muxval = _val, \
52 }
53
54 struct axp20x_desc_function {
55 const char *name;
56 u8 muxval;
57 };
58
59 struct axp20x_desc_pin {
> 60 struct pinctrl_pin_desc pin;
61 struct axp20x_desc_function *functions;
62 };
63
64 struct axp20x_pinctrl_desc {
65 const struct axp20x_desc_pin *pins;
66 int npins;
67 unsigned int pin_base;
68 };
69
70 struct axp20x_pinctrl_function {
71 const char *name;
72 const char **groups;
73 unsigned int ngroups;
74 };
75
76 struct axp20x_pinctrl_group {
77 const char *name;
78 unsigned long config;
79 unsigned int pin;
80 };
81
82 struct axp20x_pctl {
83 struct pinctrl_dev *pctl_dev;
84 struct device *dev;
85 struct gpio_chip chip;
86 struct regmap *regmap;
87 const struct axp20x_pinctrl_desc *desc;
88 struct axp20x_pinctrl_group *groups;
89 unsigned int ngroups;
90 struct axp20x_pinctrl_function *functions;
91 unsigned int nfunctions;
92 };
93
94 static const struct axp20x_desc_pin axp209_pins[] = {
> 95 AXP20X_PIN(AXP20X_PINCTRL_PIN(0, "GPIO0", (void *)AXP20X_GPIO0_CTRL),
96 AXP20X_FUNCTION(0x0, "gpio_out"),
97 AXP20X_FUNCTION(0x2, "gpio_in"),
98 AXP20X_FUNCTION(0x3, "ldo"),
99 AXP20X_FUNCTION(0x4, "adc")),
100 AXP20X_PIN(AXP20X_PINCTRL_PIN(1, "GPIO1", (void *)AXP20X_GPIO1_CTRL),
101 AXP20X_FUNCTION(0x0, "gpio_out"),
102 AXP20X_FUNCTION(0x2, "gpio_in"),
103 AXP20X_FUNCTION(0x3, "ldo"),
104 AXP20X_FUNCTION(0x4, "adc")),
> 105 AXP20X_PIN(AXP20X_PINCTRL_PIN(2, "GPIO2", (void *)AXP20X_GPIO2_CTRL),
106 AXP20X_FUNCTION(0x0, "gpio_out"),
107 AXP20X_FUNCTION(0x2, "gpio_in")),
108 };
109
110 static const struct axp20x_pinctrl_desc axp20x_pinctrl_data = {
111 .pins = axp209_pins,
112 .npins = ARRAY_SIZE(axp209_pins),
113 };
114
115 static int axp20x_gpio_get(struct gpio_chip *chip, unsigned offset)
116 {
117 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
118 unsigned int val;
119 int ret;
120
121 ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
122 if (ret)
123 return ret;
124
125 return !!(val & BIT(offset + 4));
126 }
127
128 static int axp20x_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
129 {
130 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 131 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
132 unsigned int val;
133 int ret;
134
135 ret = regmap_read(pctl->regmap, pin_reg, &val);
136 if (ret)
137 return ret;
138
139 /*
140 * This shouldn't really happen if the pin is in use already,
141 * or if it's not in use yet, it doesn't matter since we're
142 * going to change the value soon anyway. Default to output.
143 */
144 if ((val & AXP20X_GPIO_FUNCTIONS) > 2)
145 return 0;
146
147 /*
148 * The GPIO directions are the three lowest values.
149 * 2 is input, 0 and 1 are output
150 */
151 return val & 2;
152 }
153
154 static void axp20x_gpio_set(struct gpio_chip *chip, unsigned int offset,
155 int value)
156 {
157 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 158 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
159
160 regmap_update_bits(pctl->regmap, pin_reg,
161 AXP20X_GPIO_FUNCTIONS,
162 value ? AXP20X_GPIO_FUNCTION_OUT_HIGH
163 : AXP20X_GPIO_FUNCTION_OUT_LOW);
164 }
165
166 static int axp20x_gpio_input(struct gpio_chip *chip, unsigned int offset)
167 {
> 168 return pinctrl_gpio_direction_input(chip->base + offset);
169 }
170
171 static int axp20x_gpio_output(struct gpio_chip *chip, unsigned int offset,
172 int value)
173 {
174 chip->set(chip, offset, value);
175
176 return 0;
177 }
178
179 static int axp20x_pmx_set(struct pinctrl_dev *pctldev, unsigned int offset,
180 u8 config)
181 {
> 182 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
183 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
184
185 return regmap_update_bits(pctl->regmap, pin_reg, AXP20X_GPIO_FUNCTIONS,
186 config);
187 }
188
189 static int axp20x_pmx_func_cnt(struct pinctrl_dev *pctldev)
190 {
191 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
192
193 return pctl->nfunctions;
194 }
195
196 static const char *axp20x_pmx_func_name(struct pinctrl_dev *pctldev,
197 unsigned int selector)
198 {
> 199 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
200
201 return pctl->functions[selector].name;
202 }
203
204 static int axp20x_pmx_func_groups(struct pinctrl_dev *pctldev,
205 unsigned int selector,
206 const char * const **groups,
207 unsigned int *num_groups)
208 {
> 209 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
210
211 *groups = pctl->functions[selector].groups;
212 *num_groups = pctl->functions[selector].ngroups;
213
214 return 0;
215 }
216
217 static struct axp20x_desc_function *
218 axp20x_pinctrl_desc_find_func_by_name(struct axp20x_pctl *pctl,
219 const char *group, const char *func)
220 {
221 const struct axp20x_desc_pin *pin;
222 struct axp20x_desc_function *desc_func;
223 int i;
224
225 for (i = 0; i < pctl->desc->npins; i++) {
226 pin = &pctl->desc->pins[i];
227
> 228 if (!strcmp(pin->pin.name, group)) {
229 desc_func = pin->functions;
230
231 while (desc_func->name) {
232 if (!strcmp(desc_func->name, func))
233 return desc_func;
234 desc_func++;
235 }
236
237 /*
238 * Pins are uniquely named. Groups are named after one
239 * pin name. If one pin matches group name but its
240 * function cannot be found, no other pin will match
241 * group name.
242 */
243 return NULL;
244 }
245 }
246
247 return NULL;
248 }
249
250 static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
251 unsigned int function, unsigned int group)
252 {
> 253 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
254 struct axp20x_pinctrl_group *g = pctl->groups + group;
255 struct axp20x_pinctrl_function *func = pctl->functions + function;
256 struct axp20x_desc_function *desc_func =
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20700 bytes --]
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-23 17:07 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
liviu.dudau-5wv7dgnIgG8@public.gmane.org, Linuxarm,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, xuwei (O),
Jason Gunthorpe,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, John Garry, zourongrong
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F931E08@lhreml507-mbx>
On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
> > > I think this is effectively what we are doing so far with patch 2/3.
> > > The problem with this patch is that we are carving out a "forbidden"
> > > IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
> > >
> > > I think that the proper solution would be to have the LPC driver to
> > > set the carveout threshold used in pci_register_io_range(),
> > > pci_pio_to_address(), pci_address_to_pio(), but this would impose
> > > a probe dependency on the LPC itself that should be probed before
> > > the PCI controller (or before any other devices calling these
> > > functions...)
> >
> > Why do you think the order matters? My point was that we should
> > be able to register any region of logical port numbers for any
> > bus here.
>
> Maybe I have not followed well so let's roll back to your previous
> comment...
>
> "we need to associate a bus address with a logical Linux port number,
> both in of_address_to_resource and in inb()/outb()"
>
> Actually of_address_to_resource() returns the port number to used
> in inb/outb(); inb() and outb() add the port number to PCI_IOBASE
> to rd/wr to the right virtual address.
Correct.
> Our LPC cannot operate on the virtual address and it operates on
> a bus address range that for LPC is also equal to the cpu address
> range and goes from 0 to 0x1000.
There is no "cpu address" here, otherwise this is correct.
> Now as I understand it is risky and not appropriate to reserve
> the logical port numbers from 0 to 0x1000 or to whatever other
> upper bound because existing systems may rely on these port numbers
> retrieved by __of_address_to_resource().
Right again.
> In this scenario I think the best thing to do would be
> in the probe function of the LPC driver:
> 1) call pci_register_io_range() passing [0, 0x1000] (that is the
> range for LPC)
pci_register_io_range() takes a physical address, not a port number,
so that would not be appropriate as you say above. We can however
add a variant that reserves a range of port numbers in io_range_list
for an indirect access method.
> 2) retrieve the logical port numbers associated to the LPC range
> by calling pci_address_to_pio() for 0 and 0x1000 and assign
> them to extio_ops_node->start and extio_ops_node->end
Again, calling pci_address_to_pio() doesn't seem right here, because
we don't have a phys_addr_t address
> 3) implement the LPC accessors to operate on the logical ports
> associated to the LPC range (in practice in the accessors
> implementation we will call pci_pio_to_address to retrieve
> the cpu address to operate on)
Please don't proliferate the use of
pci_pio_to_address/pci_address_to_pio here, computing the physical
address from the logical address is trivial, you just need to
subtract the start of the range that you already use when matching
the port number range.
The only thing we need here is to make of_address_to_resource()
return the correct logical port number that was registered for
a given host device when asked to translate an address that
does not have a CPU address associated with it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/7] add binding for stm32 multifunctions timer driver
From: Benjamin Gaignard @ 2016-11-23 17:02 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Thierry Reding,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161123092148.GO10134-Re9dqnLqz4GzQB+pC5nmwQ@public.gmane.org>
2016-11-23 10:21 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On Wed, 23 Nov 2016, Benjamin Gaignard wrote:
>
>> 2016-11-22 17:52 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>> > On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
>> >
>> >> Add bindings information for stm32 timer MFD
>> >>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
>> >> ---
>> >> .../devicetree/bindings/mfd/stm32-timer.txt | 53 ++++++++++++++++++++++
>> >> 1 file changed, 53 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> new file mode 100644
>> >> index 0000000..3cefce1
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> @@ -0,0 +1,53 @@
>> >> +STM32 multifunctions timer driver
>> >
>> > "STM32 Multi-Function Timer/PWM device bindings"
>> >
>> > Doesn't this shared device have a better name?
>>
>> In SoC documentation those hardware blocks are named "advanced-control
>> timers", "general purpose timers" or "basic timers"
>> "stm32-timer" name is already used for clock source driver, that why I
>> have prefix it with mfd
>
> MFD is a Linuxisum and has no place in hardware description.
>
> Please used one of the names you mentioned above.
I will go for "st,stm32-advanced-timer"
>
> Hopefully the one that best fits.
>
>> >> +stm32 timer MFD allow to handle at the same time pwm and IIO timer devices
>> >
>> > No need for this sentence.
>> >
>> OK
>>
>> >> +Required parameters:
>> >> +- compatible: must be one of the follow value:
>> >> + "st,stm32-mfd-timer1"
>> >> + "st,stm32-mfd-timer2"
>> >> + "st,stm32-mfd-timer3"
>> >> + "st,stm32-mfd-timer4"
>> >> + "st,stm32-mfd-timer5"
>> >> + "st,stm32-mfd-timer6"
>> >> + "st,stm32-mfd-timer7"
>> >> + "st,stm32-mfd-timer8"
>> >> + "st,stm32-mfd-timer9"
>> >> + "st,stm32-mfd-timer10"
>> >> + "st,stm32-mfd-timer11"
>> >> + "st,stm32-mfd-timer12"
>> >> + "st,stm32-mfd-timer13"
>> >> + "st,stm32-mfd-timer14"
>> >
>> > We don't normally number devices.
>> >
>> > What's stopping you from simply doing:
>> >
>> > pwm1: pwm1@40010000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm2: pwm1@40020000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm3: pwm1@40030000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> >
>>
>> Because each instance of the hardware is slightly different: number of
>> pwm channels, triggers capabilities, etc ..
>> so I need to distinguish them.
>> Since it look to be a problem I will follow your suggestion and add a
>> property this driver to be able to identify each instance.
>> Do you think that "id" parameter (integer for 1 to 14) is acceptable ?
>
> Unfortunately not. IDs aren't allowed in DT.
>
> What about "pwm-chans" and "trigger"?
>
> pwm-chans : Number of available channels available
For pwm I need those 4 properties:
st,pwm-number: the number of PWM devices
st,complementary: if exist have complementary ouput
st,32bit-counter: if exist have 32 bits counter
st,breakinput-polarity: if set enable break input feature.
Is it acceptable from pwm maintainer point of view ?
> trigger : Boolean value specifying whether a timer is present
Following our discussion on IRC I will try to code for your proposal:
advanced-timer@40010000 {
compatible = "st,stm32-advanced-timer";
reg = <0x40010000 0x400>;
clocks = <&rcc 0 160>;
clock-names = "clk_int";
pwm@0 {
compatible = "st,stm32-pwm";
st,pwm-number= <4>;
st,complementary;
st,breakinput;
};
timer@0 {
reg = <1>;
compatible = "st,stm32-iio-timer";
interrupts = <27>;
triggers = <5 2 3 4>;
};
};
triggers parameter will be used to know which trigger are valid for
the IIO device
[snip]
^ permalink raw reply
* Re: [PATCH v2 1/2] regulator: max77620: add support to configure MPOK
From: Mark Brown @ 2016-11-23 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: Venkat Reddy Talla, lgirdwood, robh+dt, mark.rutland, devicetree,
linux-kernel, ldewangan, svelpula
In-Reply-To: <20161121131121.GE3917@dell>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
On Mon, Nov 21, 2016 at 01:11:21PM +0000, Lee Jones wrote:
> Mark if you want to take this patch, feel free.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-max77620-mpok
for you to fetch changes up to 983779235a4d08f94e8cda073200423e0ff01d2e:
regulator: max77620: add documentation for MPOK property (2016-11-23 16:27:42 +0000)
----------------------------------------------------------------
regulator: max77620: Implement support for MPOK bit
Allow systems to configure the MPOK bit, controlling power OK signalling
from the device.
----------------------------------------------------------------
Venkat Reddy Talla (3):
regulator: max77620: remove unused variable
regulator: max77620: add support to configure MPOK
regulator: max77620: add documentation for MPOK property
Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++
drivers/regulator/max77620-regulator.c | 47 +++++++++++++++++++++-
include/linux/mfd/max77620.h | 2 +
3 files changed, 60 insertions(+), 1 deletion(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Applied "regulator: max77620: add support to configure MPOK" to the regulator tree
From: Mark Brown @ 2016-11-23 16:31 UTC (permalink / raw)
Cc: Lee Jones, Mark Brown
In-Reply-To: <1479405276-26452-1-git-send-email-vreddytalla@nvidia.com>
The patch
regulator: max77620: add support to configure MPOK
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 383d0fca7035a12f1201277d33e8fc87c9d60c9a Mon Sep 17 00:00:00 2001
From: Venkat Reddy Talla <vreddytalla@nvidia.com>
Date: Thu, 17 Nov 2016 23:24:35 +0530
Subject: [PATCH] regulator: max77620: add support to configure MPOK
Adding support to configure regulator POK mapping bit
to control nRST_IO and GPIO1 POK function.
In tegra based platform which uses MAX20024 pmic, when
some of regulators are configured FPS_NONE(flexible power sequencer)
causes PMIC GPIO1 to go low which lead to various other rails turning off,
to avoid this MPOK bit of those regulators need to be set to 0
so that PMIC GPIO1 will not go low.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/max77620-regulator.c | 46 ++++++++++++++++++++++++++++++++++
include/linux/mfd/max77620.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/regulator/max77620-regulator.c b/drivers/regulator/max77620-regulator.c
index c39a56b41901..d088a7c79e60 100644
--- a/drivers/regulator/max77620-regulator.c
+++ b/drivers/regulator/max77620-regulator.c
@@ -80,6 +80,7 @@ struct max77620_regulator_pdata {
int suspend_fps_pd_slot;
int suspend_fps_pu_slot;
int current_mode;
+ int power_ok;
int ramp_rate_setting;
};
@@ -350,11 +351,48 @@ static int max77620_set_slew_rate(struct max77620_regulator *pmic, int id,
return 0;
}
+static int max77620_config_power_ok(struct max77620_regulator *pmic, int id)
+{
+ struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
+ struct max77620_regulator_info *rinfo = pmic->rinfo[id];
+ struct max77620_chip *chip = dev_get_drvdata(pmic->dev->parent);
+ u8 val, mask;
+ int ret;
+
+ switch (chip->chip_id) {
+ case MAX20024:
+ if (rpdata->power_ok >= 0) {
+ if (rinfo->type == MAX77620_REGULATOR_TYPE_SD)
+ mask = MAX20024_SD_CFG1_MPOK_MASK;
+ else
+ mask = MAX20024_LDO_CFG2_MPOK_MASK;
+
+ val = rpdata->power_ok ? mask : 0;
+
+ ret = regmap_update_bits(pmic->rmap, rinfo->cfg_addr,
+ mask, val);
+ if (ret < 0) {
+ dev_err(pmic->dev, "Reg 0x%02x update failed %d\n",
+ rinfo->cfg_addr, ret);
+ return ret;
+ }
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int max77620_init_pmic(struct max77620_regulator *pmic, int id)
{
struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
int ret;
+ max77620_config_power_ok(pmic, id);
+
/* Update power mode */
ret = max77620_regulator_get_power_mode(pmic, id);
if (ret < 0)
@@ -594,6 +632,12 @@ static int max77620_of_parse_cb(struct device_node *np,
np, "maxim,suspend-fps-power-down-slot", &pval);
rpdata->suspend_fps_pd_slot = (!ret) ? pval : -1;
+ ret = of_property_read_u32(np, "maxim,power-ok-control", &pval);
+ if (!ret)
+ rpdata->power_ok = pval;
+ else
+ rpdata->power_ok = -1;
+
ret = of_property_read_u32(np, "maxim,ramp-rate-setting", &pval);
rpdata->ramp_rate_setting = (!ret) ? pval : 0;
@@ -806,6 +850,8 @@ static int max77620_regulator_resume(struct device *dev)
for (id = 0; id < MAX77620_NUM_REGS; id++) {
reg_pdata = &pmic->reg_pdata[id];
+ max77620_config_power_ok(pmic, id);
+
max77620_regulator_set_fps_slots(pmic, id, false);
if (reg_pdata->active_fps_src < 0)
continue;
diff --git a/include/linux/mfd/max77620.h b/include/linux/mfd/max77620.h
index 3ca0af07fc78..ad2a9a852aea 100644
--- a/include/linux/mfd/max77620.h
+++ b/include/linux/mfd/max77620.h
@@ -180,6 +180,7 @@
#define MAX77620_SD_CFG1_FPWM_SD_MASK BIT(2)
#define MAX77620_SD_CFG1_FPWM_SD_SKIP 0
#define MAX77620_SD_CFG1_FPWM_SD_FPWM BIT(2)
+#define MAX20024_SD_CFG1_MPOK_MASK BIT(1)
#define MAX77620_SD_CFG1_FSRADE_SD_MASK BIT(0)
#define MAX77620_SD_CFG1_FSRADE_SD_DISABLE 0
#define MAX77620_SD_CFG1_FSRADE_SD_ENABLE BIT(0)
@@ -187,6 +188,7 @@
/* LDO_CNFG2 */
#define MAX77620_LDO_POWER_MODE_MASK 0xC0
#define MAX77620_LDO_POWER_MODE_SHIFT 6
+#define MAX20024_LDO_CFG2_MPOK_MASK BIT(2)
#define MAX77620_LDO_CFG2_ADE_MASK BIT(1)
#define MAX77620_LDO_CFG2_ADE_DISABLE 0
#define MAX77620_LDO_CFG2_ADE_ENABLE BIT(1)
--
2.10.2
^ permalink raw reply related
* Applied "regulator: max77620: add documentation for MPOK property" to the regulator tree
From: Mark Brown @ 2016-11-23 16:31 UTC (permalink / raw)
Cc: Rob Herring, Lee Jones, Mark Brown
In-Reply-To: <1479297161-7705-2-git-send-email-vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The patch
regulator: max77620: add documentation for MPOK property
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 983779235a4d08f94e8cda073200423e0ff01d2e Mon Sep 17 00:00:00 2001
From: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Date: Thu, 17 Nov 2016 23:24:36 +0530
Subject: [PATCH] regulator: max77620: add documentation for MPOK property
Adding documentation for maxim,power-ok-control dts property
Signed-off-by: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
index 2ad44f7e4880..9c16d51cc15b 100644
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ b/Documentation/devicetree/bindings/mfd/max77620.txt
@@ -106,6 +106,18 @@ Here supported time periods by device in microseconds are as follows:
MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
+-maxim,power-ok-control: configure map power ok bit
+ 1: Enables POK(Power OK) to control nRST_IO and GPIO1
+ POK function.
+ 0: Disables POK control.
+ if property missing, do not configure MPOK bit.
+ If POK mapping is enabled for GPIO1/nRST_IO then,
+ GPIO1/nRST_IO pins are HIGH only if all rails
+ that have POK control enabled are HIGH.
+ If any of the rails goes down(which are enabled for POK
+ control) then, GPIO1/nRST_IO goes LOW.
+ this property is valid for max20024 only.
+
For DT binding details of different sub modules like GPIO, pincontrol,
regulator, power, please refer respective device-tree binding document
under their respective sub-system directories.
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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