* Re: [PATCH 00/13] mmc: dw_mmc: cleans the codes for dwmmc controller
From: Heiko Stuebner @ 2016-11-09 18:55 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-1-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:22 CET schrieb Jaehoon Chung:
> This patchset is modified the some minor fixing and cleaning code.
> If needs to split the patches, i will re-send the patches.
>
> * Major changes
> - Use the cookie enum values like sdhci controller.
> - Remove the unnecessary codes and use stop_abort() by default.
> - Remove the obsoleted property "supports-highspeed"
> - Remove the "clock-freq-min-max" property. Instead, use "max-frequency"
> - Minimum clock value is set to 100K by default.
>
> Jaehoon Chung (13):
> mmc: dw_mmc: display the real register value on debugfs
> mmc: dw_mmc: fix the debug message for checking card's present
> mmc: dw_mmc: change the DW_MCI_FREQ_MIN from 400K to 100K
> mmc: dw_mmc: use the hold register when send stop command
> mmc: dw_mmc: call the dw_mci_prep_stop_abort() by default
> mmc: core: move the cookie's enum values from sdhci.h to mmc.h
> mmc: dw_mmc: use the cookie's enum values for post/pre_req()
> mmc: dw_mmc: remove the unnecessary mmc_data structure
patches 1-8 on rk3036, rk3288, rk3368 and rk3399 Rockchip platforms
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850
From: Peter Rosin @ 2016-11-09 18:54 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree,
Nicolas Ferre
In-Reply-To: <3d6b99e8-f19f-51fd-1676-c3a4549ec312@axentia.se>
On 2016-11-09 17:27, Peter Rosin wrote:
> On 2016-11-09 14:38, Mark Brown wrote:
>> On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote:
>>> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>> + struct device *dev = rtd->dev;
>>> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>>> + int dir = substream->stream != SNDRV_PCM_STREAM_PLAYBACK;
>>> + int div_id = dir ? ATMEL_SSC_RCMR_PERIOD : ATMEL_SSC_TCMR_PERIOD;
>>> + int period = snd_soc_params_to_frame_size(params) / 2 - 1;
>>
>> Please write the logic out as normal if statements for legibility. It's
>> a bit concerning that we even need this function, it looks like pretty
>> basic stuff that I'd expect the CPU DAI to just be doing - why can't
>> this be the default behaviour of the CPU DAI?
>
> I don't know and obviously don't have all the relevant HW to test
> changes. Do you want me to attempt such a change anyway?
> Adding Cc: Nicolas Ferre
Something like this, perhaps?
Cheers,
Peter
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 16e459aedffe..059b0b63bd51 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -380,6 +380,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
ssc_writel(ssc_p->ssc->regs, CR, SSC_BIT(CR_SWRST));
/* Clear the SSC dividers */
ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0;
+ ssc_p->forced_divider = 0;
}
spin_unlock_irq(&ssc_p->lock);
@@ -429,10 +430,12 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
break;
case ATMEL_SSC_TCMR_PERIOD:
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_TCMR_PERIOD);
ssc_p->tcmr_period = div;
break;
case ATMEL_SSC_RCMR_PERIOD:
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_RCMR_PERIOD);
ssc_p->rcmr_period = div;
break;
@@ -459,6 +462,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
u32 tfmr, rfmr, tcmr, rcmr;
int ret;
int fslen, fslen_ext;
+ u32 tcmr_period;
+ u32 rcmr_period;
/*
* Currently, there is only one set of dma params for
@@ -470,6 +475,13 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
else
dir = 1;
+ tcmr_period = ssc_p->tcmr_period;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_TCMR_PERIOD)))
+ tcmr_period = snd_soc_params_to_frame_size(params) / 2 - 1;
+ rcmr_period = ssc_p->rcmr_period;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_RCMR_PERIOD)))
+ rcmr_period = snd_soc_params_to_frame_size(params) / 2 - 1;
+
dma_params = ssc_p->dma_params[dir];
channels = params_channels(params);
@@ -524,7 +536,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -540,7 +552,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -606,7 +618,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -623,7 +635,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -650,7 +662,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
* MCK divider, and the BCLK signal is output
* on the SSC TK line.
*/
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, 1)
| SSC_BF(RCMR_START, SSC_START_RISING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -665,7 +677,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, 1)
| SSC_BF(TCMR_START, SSC_START_RISING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h
index 80b153857a88..75194f582131 100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -113,6 +113,7 @@ struct atmel_ssc_info {
unsigned short cmr_div;
unsigned short tcmr_period;
unsigned short rcmr_period;
+ unsigned int forced_divider;
struct atmel_pcm_dma_params *dma_params[2];
struct atmel_ssc_state ssc_state;
unsigned long mck_rate;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-09 18:54 UTC (permalink / raw)
To: Marek Vasut, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <a580bfa4-7852-aaf8-3a44-24da717f3d51-ynQEQJNshbs@public.gmane.org>
On 09/11/16 11:39, Marek Vasut wrote:
> On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
>> On 09/11/16 05:01, Marek Vasut wrote:
>>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>>
>>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>>
>>>>> Does that work with *all* SPI controllers?
>>>>>
>>>>
>>>> It does not - no. See my other email.
>>>
>>> And is that line an actual CS of that lattice chip or a generic input
>>> which almost works like CS?
>>>
>>
>> I mean a generic output vs. a special CS output built into the SPI
>> master of the application processor. Take a look at how spi_set_cs(..)
>> works:
>
> No. I am asking whether the signal which is INPUT on the iCE40 side is
> really a chipselect signal for the SPI bus OR something which mostly
> behaves/looks like a chipselect but is not really a chipselect.
Oh I see. The SS_B line is the SPI SlaveSelect for the configuration port.
This is the text from the datasheet:
"SPI Slave Select. Active Low. Includes an internal weak pull-up
resistor to VCC_SPI during configuration. During configuration, the
logic level sampled on this pin deter-mines the configuration mode used
by the iCE40 device. An input when sampled at the start of
configuration. An input when in SPI Peripheral configuration mode
(SPI_SS_B = Low). An output when in Master SPI Flash configuration mode."
So yes - it is a "real" SPI chip-select line.
Joel
--
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 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-09 18:47 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Caesar Wang,
Shawn Lin, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Russell King,
Matthias Brugger, Wei Xu, Andy Yan, Mark Rutland, Will Deacon,
Catalin Marinas, Heiko Stuebner
In-Reply-To: <87zil9gkcq.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/8/2016 11:54 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>> On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>>>> Add a vendor prefix and make the name more consistent by renaming it to
>>>> "snps,gadget-dma-enable".
>>>>
>>>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>>>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>>>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>>>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>>>> drivers/usb/dwc2/params.c | 9 ++++++++-
>>>> drivers/usb/dwc2/pci.c | 2 +-
>>>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> index 9472111..389a461 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>>>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>>>> Refer to usb/generic.txt
>>>> - snps,host-dma-disable: disable host DMA mode.
>>>> -- g-use-dma: enable dma usage in gadget driver.
>>>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>>>
>>> I don't see why you even have this binding. Looking through the code,
>>> you have:
>>>
>>> #define GHWCFG2_SLAVE_ONLY_ARCH 0
>>> #define GHWCFG2_EXT_DMA_ARCH 1
>>> #define GHWCFG2_INT_DMA_ARCH 2
>>>
>>> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
>>> {
>>> int valid = 1;
>>>
>>> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
>>> valid = 0;
>>> if (val < 0)
>>> valid = 0;
>>>
>>> if (!valid) {
>>> if (val >= 0)
>>> dev_err(hsotg->dev,
>>> "%d invalid for dma_enable parameter. Check HW configuration.\n",
>>> val);
>>> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
>>> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
>>> }
>>>
>>> hsotg->core_params->dma_enable = val;
>>> }
>>>
>>> which seems to hint that DMA support is discoverable. If there is DMA,
>>> why would disable it?
>>>
>>
>> Yes that's the case and I would prefer to make it discoverable and
>> enabled by default.
>>
>> But the legacy behavior has always been like this because DMA was
>> never fully implemented in the gadget driver and it was an opt-in
>> feature. Periodic support was only added recently.
>
> legacy behavior can be changed if another 'policy' makes more
> sense. IMHO, whatever can be discovered in runtime, should be enabled by
> default. That way, we force people to use it and find bugs in certain
> features.
Sounds good to me. I'll make the changes.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:43 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden
Cc: BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Srinath Mannam
In-Reply-To: <132c772b-d4b9-c4b6-2eca-0393e7c995f9-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Hi Adrian/Ulf,
Please ignore my comments in last email I sent out. The v2 patch
documentation matches the code and is good. I am confusing myself
between internal versions and external upstream versions of this code.
On 16-11-09 10:38 AM, Scott Branden wrote:
> Hi Adrian/Ulf,
>
> On 16-11-08 01:55 AM, Adrian Hunter wrote:
>> On 01/11/16 18:37, Scott Branden wrote:
>>> Add bytewise register accesses support for newer versions of IPROC
>>> SDHCI controllers.
>>> Previous sdhci-iproc versions of SDIO controllers
>>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>>> accesses.
>>>
>>> Signed-off-by: Srinath Mannam <srinath.mannam-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>
>> This is unchanged from V1 which I acked, so:
> I updated the binding name in the documentation but forgot to change it
> in this patch. Now that Rob has ack'd the binding documentation I will
> send out an updated patch with binding string in the code matching the
> ack'd documentation.
Ignore this - PATCH v2 is good.
>
>>
>> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>
> With the minor change I will add your ack to the next version I send out.
>
> Thanks,
> Scott
--
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 v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-09 18:39 UTC (permalink / raw)
To: Joel Holdsworth, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi, Clifford Wolf
In-Reply-To: <5828eb84-ab29-49e2-34f0-3cd7e527ca66@airwebreathe.org.uk>
On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
> On 09/11/16 05:01, Marek Vasut wrote:
>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>
>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>
>>>> Does that work with *all* SPI controllers?
>>>>
>>>
>>> It does not - no. See my other email.
>>
>> And is that line an actual CS of that lattice chip or a generic input
>> which almost works like CS?
>>
>
> I mean a generic output vs. a special CS output built into the SPI
> master of the application processor. Take a look at how spi_set_cs(..)
> works:
No. I am asking whether the signal which is INPUT on the iCE40 side is
really a chipselect signal for the SPI bus OR something which mostly
behaves/looks like a chipselect but is not really a chipselect.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c?id=refs/tags/v4.9-rc4#n695
>
>
> static void spi_set_cs(struct spi_device *spi, bool enable)
> {
> if (spi->mode & SPI_CS_HIGH)
> enable = !enable;
>
> if (gpio_is_valid(spi->cs_gpio))
> gpio_set_value(spi->cs_gpio, !enable);
> else if (spi->master->set_cs)
> spi->master->set_cs(spi, !enable);
> }
>
> So on some SPI masters, spi->master->set_cs is handled separately from
> normal GPIOs. Hence why I want to use this machinery, rather than doing
> it with a GPIO.
This is not relevant. FYI: using separate GPIO as a SPI chip select has
it's own problems.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-09 18:38 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden
Cc: BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Srinath Mannam
In-Reply-To: <c94dc018-5a2d-d50b-5746-43ae7fc258ce-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hi Adrian/Ulf,
On 16-11-08 01:55 AM, Adrian Hunter wrote:
> On 01/11/16 18:37, Scott Branden wrote:
>> Add bytewise register accesses support for newer versions of IPROC
>> SDHCI controllers.
>> Previous sdhci-iproc versions of SDIO controllers
>> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
>> accesses.
>>
>> Signed-off-by: Srinath Mannam <srinath.mannam-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> This is unchanged from V1 which I acked, so:
I updated the binding name in the documentation but forgot to change it
in this patch. Now that Rob has ack'd the binding documentation I will
send out an updated patch with binding string in the code matching the
ack'd documentation.
>
> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
With the minor change I will add your ack to the next version I send out.
Thanks,
Scott
--
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 v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-09 18:37 UTC (permalink / raw)
To: Marek Vasut, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi, Clifford Wolf
In-Reply-To: <f7917987-a4cb-2840-8128-07eebd242c17@denx.de>
On 09/11/16 05:01, Marek Vasut wrote:
> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>> On the whole, I don't think the zero-length transfers are too
>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>
>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>
>>> Does that work with *all* SPI controllers?
>>>
>>
>> It does not - no. See my other email.
>
> And is that line an actual CS of that lattice chip or a generic input
> which almost works like CS?
>
I mean a generic output vs. a special CS output built into the SPI
master of the application processor. Take a look at how spi_set_cs(..)
works:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi.c?id=refs/tags/v4.9-rc4#n695
static void spi_set_cs(struct spi_device *spi, bool enable)
{
if (spi->mode & SPI_CS_HIGH)
enable = !enable;
if (gpio_is_valid(spi->cs_gpio))
gpio_set_value(spi->cs_gpio, !enable);
else if (spi->master->set_cs)
spi->master->set_cs(spi, !enable);
}
So on some SPI masters, spi->master->set_cs is handled separately from
normal GPIOs. Hence why I want to use this machinery, rather than doing
it with a GPIO.
Joel
^ permalink raw reply
* Re: [v16, 0/7] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-11-09 18:27 UTC (permalink / raw)
To: Yangbo Lu
Cc: Mark Rutland, Greg Kroah-Hartman, Xiaobo Xie, Minghuan Lian,
linux-clk, Qiang Zhao, Russell King, Bhupesh Sharma,
Jochen Friedrich, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Scott Wood, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Leo Li,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Kumar Gala,
linuxppc-dev-uLR06cmDAlZmR6Xm/wNWPw
In-Reply-To: <1478661252-42439-1-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
- i2c-list
On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 15 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first four patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other three patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> ---
> Changes for v15:
> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
> since the work had been done by below patch on ShawnGuo's linux tree.
> 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
> and DCFG'
> - Fixed error code issue in guts driver
> Changes for v16:
> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
> - Added a bug-fix patch from Geert
> ---
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Geert Uytterhoeven (1):
> base: soc: Check for NULL SoC device attributes
>
> Yangbo Lu (5):
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 70 ++++++
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/soc/Kconfig | 3 +-
> drivers/soc/fsl/Kconfig | 18 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 236 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++-----
> include/linux/sys_soc.h | 3 +
> 13 files changed, 447 insertions(+), 51 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> --
> 2.1.0.27.g96db324
>
Thanks, applied on my mmc tree for next!
I noticed that some DT compatibles weren't documented, according to
checkpatch. Please fix that asap!
Kind regards
Ulf Hansson
^ permalink raw reply
* Re: [PATCH v9 1/3] clk: qcom: Add support for SMD-RPM Clocks
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-2-georgi.djakov@linaro.org>
On Wed, Nov 02, 2016 at 05:56:56PM +0200, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_smd_rpm driver to communicate with RPM.
> Such platforms are msm8916, apq8084 and msm8974.
>
> The RPM is a dedicated hardware engine for managing the shared
> SoC resources in order to keep the lowest power profile. It
> communicates with other hardware subsystems via shared memory
> and accepts clock requests, aggregates the requests and turns
> the clocks on/off or scales them on demand.
>
> This driver is based on the codeaurora.org driver:
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 36 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 16 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-smd-rpm.c | 571 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 45 ++
> 5 files changed, 669 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> create mode 100644 drivers/clk/qcom/clk-smd-rpm.c
> create mode 100644 include/dt-bindings/clock/qcom,rpmcc.h
^ permalink raw reply
* Re: [PATCH v9 2/3] clk: qcom: Add support for RPM Clocks
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-3-georgi.djakov@linaro.org>
On Wed, Nov 02, 2016 at 05:56:57PM +0200, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_rpm driver to communicate with RPM.
> Such platforms are apq8064 and msm8960.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/qcom/Kconfig | 13 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-rpm.c | 489 +++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 24 +
> 5 files changed, 528 insertions(+)
> create mode 100644 drivers/clk/qcom/clk-rpm.c
^ permalink raw reply
* Re: [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Linus Walleij, Joel Stanley, Mark Rutland, linux-gpio,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1478097481-14895-5-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:59AM +1030, Andrew Jeffery wrote:
> The System Control Unit IP block in the Aspeed SoCs is typically where
> the pinmux configuration is found, but not always. A number of pins
> depend on state in one of LPC Host Control (LPCHC) or SoC Display
> Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> means to adjust these as necessary.
>
> We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> used as an arbitration layer between the relevant driver and the pinctrl
> subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> drivers by phandles in the devicetree, and are selected during a mux
> request by querying a new 'ip' member in struct aspeed_sig_desc.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Since v1:
>
> The change is now proactive: instead of reporting that we need to flip bits in
> controllers we can't access, the patch provides access via regmaps for the
> relevant controllers. The implementation also splits out the IP block ID into
> its own variable rather than packing the value into the upper bits of the reg
> member of struct aspeed_sig_desc. This drives some churn in the diff, but I've
> tried to minimise it.
>
> .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 66 +++++++++++++---------
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++++++++---
> 5 files changed, 144 insertions(+), 61 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> index 2ad18c4ea55c..115b0cce6c1c 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> The Aspeed SoCs vary in functionality inside a generation but have a common mux
> device register layout.
>
> -Required properties:
> -- compatible : Should be any one of the following:
> - "aspeed,ast2400-pinctrl"
> - "aspeed,g4-pinctrl"
> - "aspeed,ast2500-pinctrl"
> - "aspeed,g5-pinctrl"
> +Required properties for g4:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2400-pinctrl"
> + "aspeed,g4-pinctrl"
> +
> +Required properties for g5:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2500-pinctrl"
> + "aspeed,g5-pinctrl"
> +
> +- aspeed,external-nodes: A cell of phandles to external controller nodes:
> + 0: compatible with "aspeed,ast2500-gfx", "syscon"
> + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>
> The pin controller node should be a child of a syscon node with the required
> property:
> @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
> TIMER7 TIMER8 VGABIOSROM
>
>
> -Examples:
> +g4 Example:
>
> syscon: scu@1e6e2000 {
> compatible = "syscon", "simple-mfd";
> @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> };
> };
>
> +g5 Example:
> +
> +apb {
> + gfx: display@1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> + };
> +
> + lpchc: lpchc@1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
> + };
> +
> + syscon: scu@1e6e2000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + pinctrl: pinctrl {
Why the single child node here? Doesn't look like any reason for it in
the example.
> + compatible = "aspeed,g5-pinctrl";
> + aspeed,external-nodes = <&gfx, &lpchc>;
> +
> + pinctrl_i2c3_default: i2c3_default {
> + function = "I2C3";
> + groups = "I2C3";
> + };
> + };
> + };
> +};
> +
> Please refer to pinctrl-bindings.txt in this directory for details of the
> common pinctrl bindings used by client devices.
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Linus Walleij, Joel Stanley, Mark Rutland, linux-gpio,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1478097481-14895-3-git-send-email-andrew@aj.id.au>
On Thu, Nov 03, 2016 at 01:07:57AM +1030, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
The register space can't be split to 2 nodes?
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
I think perhaps we should drop the syscon here and the driver should
just register as a syscon.
Rob
^ permalink raw reply
* Re: [PATCHv3 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, arnd-r2nGTMty4D4,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478097178-24341-2-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
On Wed, Nov 02, 2016 at 09:32:55AM -0500, tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org wrote:
> From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
>
> Signed-off-by: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> v2 Change compatible string -mon to -monitor for clarity
> v3 Replace node name a10sr_monitor with just monitor.
> Replace node name a10sr_gpio with just gpio.
> ---
> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-oxnas,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20161102140237.6955-3-narmstrong@baylibre.com>
On Wed, Nov 02, 2016 at 03:02:37PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Andi Shyti, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie, linux-media, devicetree, linux-leds, linux-kernel
In-Reply-To: <70e31ed5-e1ec-cac3-3c3d-02c75f1418bd@samsung.com>
On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote:
> On 11/03/2016 11:10 AM, Andi Shyti wrote:
> > Hi Jacek,
> >
> > > Only DT bindings of LED class drivers should be placed in
> > > Documentation/devicetree/bindings/leds. Please move it to the
> > > media bindings.
> >
> > that's where I placed it first, but Rob asked me to put it in the
> > LED directory and Cc the LED mailining list.
> >
> > That's the discussion of the version 2:
> >
> > https://lkml.org/lkml/2016/9/12/380
> >
> > Rob, Jacek, could you please agree where I can put the binding?
>
> I'm not sure if this is a good approach. I've noticed also that
> backlight bindings have been moved to leds, whereas they don't look
> similarly.
>
> We have common.txt LED bindings, that all LED class drivers' bindings
> have to follow. Neither backlight bindings nor these ones do that,
> which introduces some mess.
And there are probably LED bindings that don't follow common.txt either.
> Eventually adding a sub-directory, e.g. remote_control could make it
> somehow logically justified, but still - shouldn't bindings be
> placed in the documentation directory related to the subsystem of the
> driver they are predestined to?
No. While binding directories often mirror the driver directories, they
are not the same. Bindings are grouped by types of h/w and IR LEDs are a
type of LED.
If you prefer a sub-dir, that is fine with me.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Cédric Le Goater
Cc: devicetree, Corey Minyard, Arnd Bergmann, Joel Stanley,
openipmi-developer, linux-arm-kernel
In-Reply-To: <1478073426-3714-2-git-send-email-clg@kaod.org>
On Wed, Nov 02, 2016 at 08:57:04AM +0100, Cédric Le Goater wrote:
> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> other is H8S/2168 compliant.
>
> The current ipmi/bt-bmc driver implements the IPMI version and we
> should reflect its nature in the compatible node name using
> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> latter should be used for a H8S interface driver if it is implemented
> one day.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> .../ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} | 4 ++--
Acked-by: Rob Herring <robh@kernel.org>
> drivers/char/ipmi/bt-bmc.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/ipmi/{aspeed,ast2400-bt-bmc.txt => aspeed,ast2400-ibt-bmc.txt} (85%)
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
^ permalink raw reply
* Re: [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Tony Lindgren, Linux OMAP Mailing List, Tero Kristo, Sekhar Nori,
Nishanth Menon, Device Tree Mailing List, Linux ARM Mailing List,
Lee Jones, Keerthy
In-Reply-To: <e5619d78-5752-c8fb-8a11-6629c4b7c3f6-l0cyMroinI0@public.gmane.org>
On Wed, Nov 02, 2016 at 10:58:40AM +0530, Lokesh Vutla wrote:
>
>
> On Monday 31 October 2016 02:11 AM, Rob Herring wrote:
> > On Fri, Oct 21, 2016 at 04:08:36PM +0530, Lokesh Vutla wrote:
> >> In order to have a proper topology of regulators for a platform, each
> >> registering regulator needs to populate supply_name field for identifying
> >> its supply's name. Add supply_name field for lp873x regulators.
> >>
> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> Cc: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> >> drivers/regulator/lp873x-regulator.c | 1 +
> >> 2 files changed, 9 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> index 52766c2..998837a 100644
> >> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> >> @@ -7,6 +7,9 @@ Required properties:
> >> - #gpio-cells: Should be two. The first cell is the pin number and
> >> the second cell is used to specify flags.
> >> See ../gpio/gpio.txt for more information.
> >> + - xxx-in-supply: Phandle to parent supply node of each regulator
> >> + populated under regulators node. xxx should match
> >> + the supply_name populated in driver.
> >
> > The driver is irrelevant. This should reference a list in this document.
>
> okay. See if the below updated patch is fine.
>
> -----------------------------8<----------------------------8<----------------------------
> From 666f925423fa35c7bfcc77fa3c883cbea5d8ef8e Mon Sep 17 00:00:00 2001
> From: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> Date: Wed, 21 Sep 2016 11:50:49 +0530
> Subject: [PATCH v3] regulator: lp873x: Add support for populating input
> supply
>
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v4] Documentation: dtb: lm87: Add hwmon binding documentation.
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Mahoda Ratnayaka
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA, Chris Packham
In-Reply-To: <20161102025804.9215-1-mahoda.ratnayaka-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
On Wed, Nov 02, 2016 at 03:58:04PM +1300, Mahoda Ratnayaka wrote:
> This patch adds lm87 hwmon device tree node documentation.
>
> Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
> ---
>
> Notes:
> Changes since v1:
> As suggested include all the changes are moved in
> to the same patch and the all the optional properties
> are now defined instead of using a single variable to
> indicate those properties.
>
> Changes since v2:
> Changed has-vcc-5v to use regulator binding and fixed
> a minor copy paste mistake.
>
> Changes since v3:
> Update the vcc-supply description.
>
> Documentation/devicetree/bindings/hwmon/lm87.txt | 30 ++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/lm87.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Scott Branden
Cc: Mark Rutland, devicetree, Ulf Hansson, Anup Patel, Scott Branden,
Ray Jui, linux-mmc, Adrian Hunter, linux-kernel,
BCM Kernel Feedback, linux-arm-kernel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On Tue, Nov 01, 2016 at 09:37:56AM -0700, Scott Branden wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] binding: irqchip: mtk-cirq: Add binding document
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Youlin Pei
Cc: Marc Zyngier, Matthias Brugger, Thomas Gleixner, Jason Cooper,
Mark Rutland, Russell King, linux-kernel, devicetree,
linux-arm-kernel, linux-mediatek, srv_heupstream, hongkun.cao,
yong.wu, erin.lo, chieh-jay.liu
In-Reply-To: <1478001122-8664-2-git-send-email-youlin.pei@mediatek.com>
On Tue, Nov 01, 2016 at 07:52:00PM +0800, Youlin Pei wrote:
> This commit adds the device tree binding document for
> the mediatek cirq.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
> ---
> .../interrupt-controller/mediatek,cirq.txt | 30 ++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> new file mode 100644
> index 0000000..84e8123
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> @@ -0,0 +1,30 @@
> +* Mediatek 27xx cirq
> +
> +In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
> +works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
s/works/work/
> +The external interrupts (outside MCUSYS) will feed through CIRQ and connect
> +to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
> +interrupts and generated a pulse signal to parent interrupt controller when
s/generated/generate/
> +flush command is executed. With CIRQ, MCUSYS can be completely turned off
> +to improve the system power consumption without losing interrupts.
> +
> +Required properties:
> +- compatible: should be: "mediatek,mtk-cirq".
This should be SoC specific. This is fine as a fallback if the same
block is in many SoCs, but mediatek and mtk is a bit redundant.
> +- interrupt-controller : Identifies the node as an interrupt controller.
> +- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of irq parent for cirq. The parent must
> + use the same interrupt-cells format as GIC.
> +- reg: Physical base address of the cirq registers and length of memory
> + mapped region.
> +- mediatek,ext-irq-start: Identifies external irq start number in different
> + SOCs.
Wouldn't this always be 32 if the GIC is the parent? If 32 is the common
case, then use the SoC compatible to determine this value.
> +
> +Example:
> + cirq: interrupt-controller@10204000 {
> + compatible = "mediatek,mtk-cirq";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&sysirq>;
> + reg = <0 0x10204000 0 0x4000>;
> + mediatek,ext-irq-start = <32>;
> + };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Paul Cercueil
Cc: Johannes Berg, David S . Miller, Mark Rutland, netdev, devicetree,
linux-kernel, linux-wireless, Maarten ter Huurne
In-Reply-To: <20161101105840.24313-1-paul@crapouillou.net>
On Tue, Nov 01, 2016 at 11:58:39AM +0100, Paul Cercueil wrote:
> This document gives information about how to write a devicetree
> node that corresponds to the rfkill-regulator driver.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../devicetree/bindings/net/rfkill-regulator.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/rfkill-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/net/rfkill-regulator.txt b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
> new file mode 100644
> index 0000000..aac2fe1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
> @@ -0,0 +1,18 @@
> +Device tree bindings for the rfkill-regulator driver
> +
> +Required properties:
> + - compatible: should be "rfkill-regulator"
> + - rfkill-name: the name of this rfkill device
> + - rfkill-type: the type of this rfkill device;
> + must correspond to a valid rfkill_type from <uapi/linux/rfkill.h>
> + - vrfkill-supply: phandle to a regulator
My understanding is it is generally felt that using the regulator enable
GPIO commonly found on WiFi chips for rfkill is an abuse of rfkill as it
is more that just an RF disable. From a DT standpoint, this seems like
creating a binding for what a Linux driver wants. Instead, I think this
should be either a GPIO or GPIO regulator and the driver for the WiFi
chip should decide whether or not to register that as an rfkill driver.
Rob
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Rob Herring @ 2016-11-09 18:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: f.fainelli, khilman, carlo, andrew, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
> drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
> 2 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> index 8516929..065e8bd 100644
> --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> @@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
> This is a special case of a MDIO bus multiplexer. A memory-mapped device,
> like an FPGA, is used to control which child bus is connected. The mdio-mux
> node must be a child of the memory-mapped device. The driver currently only
As you're touching this sentence, this describes the binding, not a
driver. With that,
Acked-by: Rob Herring <robh@kernel.org>
> -supports devices with eight-bit registers.
> +supports devices with 8, 16 or 32-bit registers.
>
> Required properties in addition to the generic multiplexer properties:
>
> @@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
>
> - reg : integer, contains the offset of the register that controls the bus
> multiplexer. The size field in the 'reg' property is the size of
> - register, and must therefore be 1.
> + register, and must therefore be 1, 2, or 4.
>
> - mux-mask : integer, contains an eight-bit mask that specifies which
> bits in the register control the actual bus multiplexer. The
^ permalink raw reply
* Re: [PATCH V3 3/9] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Zhang Rui, Dmitry Torokhov, Guenter Roeck,
LINUX-INPUT, LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <318faafc8021e6adc683e62d57b8c031b9212e0f.1477929725.git.stwiss.opensource@diasemi.com>
On Mon, Oct 31, 2016 at 04:02:03PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Device tree binding information for DA9062 and DA9061 thermal junction
> temperature monitor.
>
> Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
> device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
> a configurable polling period for over-temperature polling.
>
> This patch also adds two examples, one for DA9062 and one for DA9061. The
> DA9061 example uses a fall-back compatible string for the DA9062.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V3 4/9] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <502d13b97c67023f2193abfa235e8884eb0ea02f.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Mon, Oct 31, 2016 at 04:02:03PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
>
> Add a da9062-onkey link to the existing onkey binding file.
>
> Add a da9062-thermal link to the new temperature monitoring binding file.
>
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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
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