* [PATCH v2 07/14] ASoC: sun4i-codec: Add support for A31 Line In playback
From: Maxime Ripard @ 2016-11-03 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-8-wens@csie.org>
On Thu, Nov 03, 2016 at 03:55:49PM +0800, Chen-Yu Tsai wrote:
> The A31 integrated codec has a stereo "Line In" input. Add support for
> it to the playback paths.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/062cbad7/attachment.sig>
^ permalink raw reply
* [PATCH v2 10/14] ASoC: sun4i-codec: Add support for A31 ADC capture path
From: Maxime Ripard @ 2016-11-03 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-11-wens@csie.org>
On Thu, Nov 03, 2016 at 03:55:52PM +0800, Chen-Yu Tsai wrote:
> The A31's internal codec capture path has a mixer in front of the ADC
> for each channel, capable of selecting various inputs, including
> microphones, line in, phone in, and the main output mixer.
>
> This patch adds the various controls, widgets and routes needed for
> audio capture from the already supported inputs on the A31.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/563cf894/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 11/14] ASoC: sun4i-codec: Add support for A31 board level audio routing
From: Maxime Ripard @ 2016-11-03 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-12-wens@csie.org>
On Thu, Nov 03, 2016 at 03:55:53PM +0800, Chen-Yu Tsai wrote:
> The A31 SoC's codec has various inputs, outputs and microphone bias
> supplies. These can be routed on the board in different ways, such as:
>
> - HPCOM may be connected to have the headphone DC coupled.
>
> - Microphones all use the MBIAS main microphone supply or one mic may
> use the HBIAS supply, which supports headset detection and buttons.
>
> - Line Out may be routed to an audio jack, or an onboard speaker amp
> with power controls.
>
> Add support for specifying the audio routes in the device tree.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/73c89dec/attachment.sig>
^ permalink raw reply
* [PATCH v5 5/7] net: ethernet: bgmac: device tree phy enablement
From: Rafal Milecki @ 2016-11-03 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478106488-11779-6-git-send-email-jon.mason@broadcom.com>
On 11/02/2016 06:08 PM, Jon Mason wrote:
> Change the bgmac driver to allow for phy's defined by the device tree
This is a late review, I know, sorry... :(
> +static int bcma_phy_direct_connect(struct bgmac *bgmac)
> +{
> + struct fixed_phy_status fphy_status = {
> + .link = 1,
> + .speed = SPEED_1000,
> + .duplex = DUPLEX_FULL,
> + };
> + struct phy_device *phy_dev;
> + int err;
> +
> + phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> + if (!phy_dev || IS_ERR(phy_dev)) {
> + dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> + return -ENODEV;
> + }
> +
> + err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> + PHY_INTERFACE_MODE_MII);
> + if (err) {
> + dev_err(bgmac->dev, "Connecting PHY failed\n");
> + return err;
> + }
> +
> + return err;
> +}
This bcma specific function looks exactly the same as...
> +static int platform_phy_direct_connect(struct bgmac *bgmac)
> +{
> + struct fixed_phy_status fphy_status = {
> + .link = 1,
> + .speed = SPEED_1000,
> + .duplex = DUPLEX_FULL,
> + };
> + struct phy_device *phy_dev;
> + int err;
> +
> + phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
> + if (!phy_dev || IS_ERR(phy_dev)) {
> + dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
> + return -ENODEV;
> + }
> +
> + err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
> + PHY_INTERFACE_MODE_MII);
> + if (err) {
> + dev_err(bgmac->dev, "Connecting PHY failed\n");
> + return err;
> + }
> +
> + return err;
> +}
This one.
Would that make sense to keep bgmac_phy_connect_direct and just use it in
bcma/platform code?
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-11-03 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+TqcAjzAJNfikRKfccmYX778FuxNSeVbT1dGU0hswxZWjjg@mail.gmail.com>
Hi Bruno,
On 11/02/2016 07:23 PM, Bruno Herrera wrote:
> On Wed, Nov 2, 2016 at 4:05 PM, Rados?aw Pietrzyk
> <radoslaw.pietrzyk@gmail.com> wrote:
>> Have you tried with
>>
>> sdio {
>> ...
>> compatible = "arm,primecell";
>> arm,primecell-periphid = <id_to_define>;
>> ...
>> }
>>
>> This should register proper amba device and give it an ID you wish.
>
> I'm using this:
>
> sdio: sdio at 40012c00 {
> compatible = "arm,pl18x", "arm,primecell";
> arm,primecell-periphid = <0x00480181>;
> reg = <0x40012c00 0x400>;
> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
> dma-names = "rx", "tx";
> clocks = <&rcc 0 171>;
> clock-names = "apb_pclk";
> interrupts = <49>;
> status = "disabled";
> };
>
> And on the driver side I added this:
>
> /* STM32 variants */
>
> {
>
> .id = 0x00480181,
>
> .mask = 0xf0ffffff,
>
> .data = &variant_stm32f4x9,
>
> },
>
> My .id field is the .id from variant_ux500 plus one (and what I
> believe is not valid).
> And I cannot read the ID from STM32 IP because it always return zero.
> Maybe someone from ST(@Alex) can get the real ID. ;)
I will have a look on it soon.
regards
alex
>
>
>>
>> 2016-11-02 17:07 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
>>>
>>> Hi
>>>
>>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>>> <alexandre.torgue@st.com> wrote:
>>>> Hi
>>>>
>>>> On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
>>>>>
>>>>> I think wlcore driver searches dma-ranges in its parent that's why sdio
>>>>> node needs it.
>>>>
>>>>
>>>> Yes I agree. In this case it is needed as you have subnode in sdio node.
>>>> So IMO empty dma-ranges could be removed from ethernet and usb node, but
>>>> kept in future sdio subnode.
>>>
>>> Now it is clear.
>>>
>>>>
>>>> Bruno,
>>>> Do you plan to push sdio support ?
>>>
>>> Yes I do, but I'm not sure how long it will take. The I had to
>>> change(and hack) the mmci code because I could not get the ID from
>>> STM32 SDIO IP.
>>> My current WIP is at @
>>>
>>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>>> I know Andrea Merello is also working on that (and he probably has a
>>> more complete patch).
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>>> <mailto:bruherrera@gmail.com>>:
>>>>>
>>>>> On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
>>>>> <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
>>>>> wrote:
>>>>> > This is weird because dma ddresses are recalculated using
>>>>> parent's
>>>>> > dma-ranges property and soc already has it so there should be
>>>>> absolutely no
>>>>> > problem.
>>>>>
>>>>> These are my DTS and DTSI file.
>>>>> >
>>>>> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>>> <mailto:bruherrera@gmail.com>>:
>>>>> >>
>>>>> >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>>>>> >> <radoslaw.pietrzyk@gmail.com
>>>>> <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
>>>>> >> > Have you defined your sdio node within soc node ?
>>>>> >>
>>>>> >> It is in the SOC node of the DSTI file.
>>>>> >>
>>>>> >> >
>>>>> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>>>>> <mailto:bruherrera@gmail.com>>:
>>>>> >> >>
>>>>> >> >> Hi Alex,
>>>>> >> >>
>>>>> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>>>>> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>>> wrote:
>>>>> >> >> > Hi Bruno,
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>>>>> >> >> >>
>>>>> >> >> >> Hi Alex,
>>>>> >> >> >>
>>>>> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>>>>> >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>>> wrote:
>>>>> >> >> >>>
>>>>> >> >> >>> Hi Bruno,
>>>>> >> >> >>>
>>>>> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>> Hi Alexandre,
>>>>> >> >> >>>>
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>>>>> start address
>>>>> >> >> >>>>> remapping
>>>>> >> >> >>>>> (to @0) to boost performances. A DMA translation
>>>>> through
>>>>> >> >> >>>>> "dma-ranges"
>>>>> >> >> >>>>> property was needed for other masters than the M4 CPU.
>>>>> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>>>>> this DMA
>>>>> >> >> >>>>> translation.
>>>>> >> >> >>>>> This patches moves this DMA translation definition from
>>>>> stm32f429
>>>>> >> >> >>>>> soc
>>>>> >> >> >>>>> file
>>>>> >> >> >>>>> to board files.
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> Signed-off-by: Alexandre TORGUE
>>>>> <alexandre.torgue@st.com
>>>>> <mailto:alexandre.torgue@st.com>>
>>>>>
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>>> index 13c7cd2..a763c15 100644
>>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>>> @@ -82,6 +82,10 @@
>>>>> >> >> >>>>> };
>>>>> >> >> >>>>> };
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> + soc {
>>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>>> 0x10000000>;
>>>>> >> >> >>>>> + };
>>>>> >> >> >>>>> +
>>>>> >> >> >>>>> usbotg_hs_phy: usbphy {
>>>>> >> >> >>>>> #phy-cells = <0>;
>>>>> >> >> >>>>> compatible = "usb-nop-xceiv";
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>> Shouldn't also the peripheral dma-ranges property move
>>>>> to
>>>>> board
>>>>> >> >> >>>> specific
>>>>> >> >> >>>> too?
>>>>> >> >> >>>> I had this patch for while but I didn't had the time to
>>>>> submit:
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>>>>> ysterday on
>>>>> >> >> >>> IIRC,
>>>>> >> >> >>> empty dma-ranges is not needed. Can you test on your side
>>>>> by
>>>>> >> >> >>> removing
>>>>> >> >> >>> dma-ranges in usb node please ?
>>>>> >> >> >>
>>>>> >> >> >> Unfortunately will take a time for me to set up this
>>>>> environment on
>>>>> >> >> >> the STM32F4-EVAL board.
>>>>> >> >> >> And on the discovery boards we dont have this scenario.
>>>>> That was the
>>>>> >> >> >> main reason I did not submit the patch right away.
>>>>> >> >> >> My conclusion and I might be wrong but is based on the my
>>>>> tests with
>>>>> >> >> >> SDIO device at STM32F469I-DISCO board.
>>>>> >> >> >>
>>>>> >> >> >> I started this issue as discussion at ST Forum but Maxime
>>>>> gave me
>>>>> >> >> >> the
>>>>> >> >> >> hint.
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>>
>>>>>
>>>>> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>>>>>
>>>>>
>>>>> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
>>>>> >> >> >>
>>>>> >> >> >>> I will push a v2 by removing empty dma-ranges if tests
>>>>> are
>>>>> ok in
>>>>> >> >> >>> your
>>>>> >> >> >>> side.
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> From my understating/conclusion is: when empty
>>>>> property(dma-ranges)
>>>>> >> >> >> is
>>>>> >> >> >> the device node, the mapping will be taken in
>>>>> consideration
>>>>> when
>>>>> >> >> >> using
>>>>> >> >> >> DMA otherwise the mapping is ignored.
>>>>> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>>>>> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>>>>> question
>>>>> >> >> >> so
>>>>> >> >> >> I suppose it can work without the property.
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > For sure translation has to be done but I'm not sure that
>>>>> an
>>>>> empty
>>>>> >> >> > "dma-ranges" is needed in device node to activate it. For
>>>>> Ethernet
>>>>> >> >> > empty
>>>>> >> >> > "dma-ranges" is not needed. I will try with usb.
>>>>> >> >>
>>>>> >> >> In the case of SDIO it is needed. As example this is my
>>>>> working SDIO
>>>>> >> >> node:
>>>>> >> >>
>>>>> >> >> sdio: sdio at 40012c00 {
>>>>> >> >> compatible = "arm,pl18x", "arm,primecell";
>>>>> >> >> arm,primecell-periphid = <0x00480181>;
>>>>> >> >> reg = <0x40012c00 0x400>;
>>>>> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>>>>> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>>>>> >> >> dma-names = "rx", "tx";
>>>>> >> >> clocks = <&rcc 0 171>;
>>>>> >> >> clock-names = "apb_pclk";
>>>>> >> >> interrupts = <49>;
>>>>> >> >> status = "disabled";
>>>>> >> >> };
>>>>> >> >>
>>>>> >> >> &sdio {
>>>>> >> >> status = "okay";
>>>>> >> >> vmmc-supply = <&wlan_en>;
>>>>> >> >> bus-width = <4>;
>>>>> >> >> max-frequency = <24000000>;
>>>>> >> >> pinctrl-names = "default";
>>>>> >> >> pinctrl-0 = <&sdio_pins>;
>>>>> >> >> ti,non-removable;
>>>>> >> >> ti,needs-special-hs-handling;
>>>>> >> >> dma-ranges;
>>>>> >> >> cap-power-off-card;
>>>>> >> >> keep-power-in-suspend;
>>>>> >> >>
>>>>> >> >> #address-cells = <1>;
>>>>> >> >> #size-cells = <0>;
>>>>> >> >> wlcore: wlcore at 0 {
>>>>> >> >> compatible = "ti,wl1835";
>>>>> >> >> reg = <2>;
>>>>> >> >> interrupt-parent = <&gpioa>;
>>>>> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>>>>> >> >> };
>>>>> >> >> };
>>>>> >> >>
>>>>> >> >> >
>>>>> >> >> > alex
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >>
>>>>> >> >> >>>
>>>>> >> >> >>> Thanks in advance
>>>>> >> >> >>> Alex
>>>>> >> >> >>>
>>>>> >> >> >>>
>>>>> >> >> >>>>
>>>>> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
>>>>> <mailto:bruherrera@gmail.com>>
>>>>>
>>>>> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>>>>> >> >> >>>>
>>>>> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board
>>>>> not
>>>>> at dtsi
>>>>> >> >> >>>> file
>>>>> >> >> >>>>
>>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>> index 6bfc595..2a22a82 100644
>>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>> >> >> >>>> @@ -52,6 +52,10 @@
>>>>> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL
>>>>> board";
>>>>> >> >> >>>> compatible = "st,stm32429i-eval",
>>>>> "st,stm32f429";
>>>>> >> >> >>>>
>>>>> >> >> >>>> + soc {
>>>>> >> >> >>>> + dma-ranges = <0xC0000000 0x0
>>>>> 0x10000000>;
>>>>> >> >> >>>> + };
>>>>> >> >> >>>> +
>>>>> >> >> >>>> chosen {
>>>>> >> >> >>>> bootargs = "root=/dev/ram
>>>>> rdinit=/linuxrc";
>>>>> >> >> >>>> stdout-path = "serial0:115200n8";
>>>>> >> >> >>>> @@ -96,6 +100,7 @@
>>>>> >> >> >>>>
>>>>> >> >> >>>> ðernet0 {
>>>>> >> >> >>>> status = "okay";
>>>>> >> >> >>>> + dma-ranges;
>>>>> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
>>>>> >> >> >>>> pinctrl-names = "default";
>>>>> >> >> >>>> phy-mode = "mii-id";
>>>>> >> >> >>>> @@ -116,6 +121,7 @@
>>>>> >> >> >>>> };
>>>>> >> >> >>>>
>>>>> >> >> >>>> &usbotg_hs {
>>>>> >> >> >>>> + dma-ranges;
>>>>> >> >> >>>> dr_mode = "host";
>>>>> >> >> >>>> phys = <&usbotg_hs_phy>;
>>>>> >> >> >>>> phy-names = "usb2-phy";
>>>>> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>> index 7d624a2..697a133 100644
>>>>> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>> @@ -59,7 +59,6 @@
>>>>> >> >> >>>> };
>>>>> >> >> >>>>
>>>>> >> >> >>>> soc {
>>>>> >> >> >>>> - dma-ranges = <0xc0000000 0x0
>>>>> 0x10000000>;
>>>>> >> >> >>>>
>>>>> >> >> >>>> timer2: timer at 40000000 {
>>>>> >> >> >>>> compatible = "st,stm32-timer";
>>>>> >> >> >>>> @@ -472,13 +471,11 @@
>>>>> >> >> >>>> st,syscon = <&syscfg 0x4>;
>>>>> >> >> >>>> snps,pbl = <8>;
>>>>> >> >> >>>> snps,mixed-burst;
>>>>> >> >> >>>> - dma-ranges;
>>>>> >> >> >>>> status = "disabled";
>>>>> >> >> >>>> };
>>>>> >> >> >>>>
>>>>> >> >> >>>> usbotg_hs: usb at 40040000 {
>>>>> >> >> >>>> compatible = "snps,dwc2";
>>>>> >> >> >>>> - dma-ranges;
>>>>> >> >> >>>> reg = <0x40040000 0x40000>;
>>>>> >> >> >>>> interrupts = <77>;
>>>>> >> >> >>>> clocks = <&rcc 0 29>;
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>>> index 0596d60..3a1cfdd 100644
>>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>>> >> >> >>>>> @@ -59,8 +59,6 @@
>>>>> >> >> >>>>> };
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> soc {
>>>>> >> >> >>>>> - dma-ranges = <0xc0000000 0x0
>>>>> 0x10000000>;
>>>>> >> >> >>>>> -
>>>>> >> >> >>>>> timer2: timer at 40000000 {
>>>>> >> >> >>>>> compatible = "st,stm32-timer";
>>>>> >> >> >>>>> reg = <0x40000000 0x400>;
>>>>> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>>>> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>>>> >> >> >>>>> index 9e73656..c2213c0 100644
>>>>> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>>> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>>> >> >> >>>>> @@ -64,6 +64,10 @@
>>>>> >> >> >>>>> aliases {
>>>>> >> >> >>>>> serial0 = &usart3;
>>>>> >> >> >>>>> };
>>>>> >> >> >>>>> +
>>>>> >> >> >>>>> + soc {
>>>>> >> >> >>>>> + dma-ranges = <0xc0000000 0x0
>>>>> 0x10000000>;
>>>>> >> >> >>>>> + };
>>>>> >> >> >>>>> };
>>>>> >> >> >>>>>
>>>>> >> >> >>>>> &clk_hse {
>>>>> >> >> >>>>> --
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>>
>>>>> >> >> >>>> Br.,
>>>>> >> >> >>>> Bruno
>>>>> >> >> >>>>
>>>>> >> >> >>>
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >> _______________________________________________
>>>>> >> >> linux-arm-kernel mailing list
>>>>> >> >> linux-arm-kernel at lists.infradead.org
>>>>> <mailto:linux-arm-kernel@lists.infradead.org>
>>>>> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>>>>> >> >
>>>>> >> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>
>>
^ permalink raw reply
* [PATCH 09/13] mmc: dw_mmc: remove the "clock-freq-min-max" property
From: Jaehoon Chung @ 2016-11-03 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20823767.hqlyMd1aKN@diego>
Hi Heiko.
On 11/03/2016 05:20 PM, Heiko St?bner wrote:
> Hi Jaehoon,
>
> Am Donnerstag, 3. November 2016, 15:21:31 schrieb Jaehoon Chung:
>> Remove the "clock-freq-min-max" property.
>> There is "max-frequency" property in drivers/mmc/core/host.c
>> It can be used for getting maximum frequency.
>>
>> And minimum clock value is assigned to 100K by default.
>> Because MMC core should check the initial clock value from
>> 400K to 100K until finding correct value.
>> It's why Minimum value puts 100K by default.
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 3 ---
>> drivers/mmc/host/dw_mmc.c | 13
>> ++++--------- 2 files changed, 4 insertions(+), 12 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index
>> 4e00e85..21c8251 100644
>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>> @@ -56,9 +56,6 @@ Optional properties:
>> is specified and the ciu clock is specified then we'll try to set the ciu
>> clock to this at probe time.
>>
>> -* clock-freq-min-max: Minimum and Maximum clock frequency for card output
>> - clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz
>> by default. -
>
> I'd think devicetree people will protest about simply removing this property
> without deprecating it first - to be backwards compatible with old devicetrees.
>
> Especially as this property was added already back in 2013, so has been in use
> for quite some time.
Thanks for pointing out. I will resend the patchset with changing this.
And maintain the backwards compatible.
Best Regards,
Jaehoon Chung
>
>
> Heiko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [linux-sunxi] [PATCH v2 04/14] ASoC: sun4i-codec: Increase DMA max burst to 8
From: Priit Laes @ 2016-11-03 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-5-wens@csie.org>
On Thu, 2016-11-03 at 15:55 +0800, Chen-Yu Tsai wrote:
> According to the DMA engine API documentation, maxburst denotes the
> largest possible size of a single transfer, so as not to overflow
> destination FIFOs as explained in this excerpt from dmaengine.h
>
> ?* @src_maxburst: the maximum number of words (note: words, as in
> ?* units of the src_addr_width member, not bytes) that can be sent
> ?* in one burst to the device. Typically something like half the
> ?* FIFO depth on I/O peripherals so you don't overflow it. This
> ?* may or may not be applicable on memory sources.
> ?* @dst_maxburst: same as src_maxburst but for destination target
> ?* mutatis mutandis.
^^ :)
>
> The TX FIFO is 64 samples deep for stereo, and the RX FIFO is 16
> samples deep. So maxburst could be 32 and 8 for TX and RX
> respectively.
>
> Unfortunately the sunxi DMA controller driver takes maxburst as
> the requested burst size, rather than a limit, and returns an error
> for unsupported values. The original value was 4, but some later
> SoCs do not officially support this burst size.
>
> This patch increases maxburst on the TX side to 8, which is supported
> by all variants of the sunxi DMA controller.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> ?sound/soc/sunxi/sun4i-codec.c | 4 ++--
> ?1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-
> codec.c
> index 61ae502a5061..d867b96d367b 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -886,12 +886,12 @@ static int sun4i_codec_probe(struct
> platform_device *pdev)
> ?
> ? /* DMA configuration for TX FIFO */
> ? scodec->playback_dma_data.addr = res->start + quirks-
> >reg_dac_txdata;
> - scodec->playback_dma_data.maxburst = 4;
> + scodec->playback_dma_data.maxburst = 8;
> ? scodec->playback_dma_data.addr_width =
> DMA_SLAVE_BUSWIDTH_2_BYTES;
> ?
> ? /* DMA configuration for RX FIFO */
> ? scodec->capture_dma_data.addr = res->start + quirks-
> >reg_adc_rxdata;
> - scodec->capture_dma_data.maxburst = 4;
> + scodec->capture_dma_data.maxburst = 8;
> ? scodec->capture_dma_data.addr_width =
> DMA_SLAVE_BUSWIDTH_2_BYTES;
> ?
> ? ret = snd_soc_register_codec(&pdev->dev, quirks->codec,
> --?
> 2.10.2
>
^ permalink raw reply
* [PATCH v2 13/14] ARM: dts: sun6i: hummingbird: Enable internal audio codec
From: Maxime Ripard @ 2016-11-03 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-14-wens@csie.org>
On Thu, Nov 03, 2016 at 03:55:55PM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 has headset and line in audio jacks and an onboard
> mic routed to the pins for the SoC's internal codec. The line out pins
> are routed to an onboard speaker amp, whose output is available on a
> pin header.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> index 9a74637f677f..48c041b75aab 100644
> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> @@ -69,6 +69,19 @@
> };
> };
>
> +&codec {
> + allwinner,audio-routing =
> + "Headphone", "HP",
> + "Speaker", "LINEOUT",
> + "LINEIN", "Line In",
> + "MIC1", "Mic",
> + "MIC2", "Headset Mic",
> + "Mic", "MBIAS",
> + "Headset Mic", "HBIAS";
> + allwinner,pa-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
> + status = "okay";
> +};
> +
> &cpu0 {
> cpu-supply = <®_dcdc3>;
> };
> @@ -152,6 +165,13 @@
> };
>
> &pio {
> + codec_pa_pin: codec_pa_pin at 0 {
> + allwinner,pins = "PH22";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
This pin group isn't used anywhere. Because of the strict thing in
pinctrl, I'd say it's better to not set it, but then, the pin group is
useless.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/81e008e2/attachment.sig>
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Linus Walleij @ 2016-11-03 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101231708.GM25787@tuxbot>
[CC Quan who made a nice hierarchical domain]
On Wed, Nov 2, 2016 at 12:17 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Tue 01 Nov 04:31 PDT 2016, Linus Walleij wrote:
>
>> On Mon, Oct 31, 2016 at 11:20 PM, Bjorn Andersson
>> <bjorn.andersson@linaro.org> wrote:
>>
>> >> + interrupt-parent = <&pm8058_gpio>;
>> >> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
>> >
>> > To remove the need of resetting the interrupt-parent in each child you
>> > can use the following form:
>> >
>> > interrupts-extended = <&pm8058_gpio 208 IRQ_TYPE_EDGE_FALLING>;
>> >
>> > But, if we correct the ssbi gpio driver then this would no longer be
>> > interrupt 208 in this parent, right?. I believe that if you say
>> > <&pmicintc 208 IRQ_TYPE_EDGE_FALLING> instead, which should work even
>> > after we correct the gpio translation.
>>
>> Yes. It should be fixed everywhere but is not related to this
>> patch. But I can do a two-patch series first fixing this and then
>> adding the gyro+accelerometer on top referencing the MFD
>> pmicintc as parent.
>>
>
> Sorry, I'm not sure I'm following.
>
> What I tried to say was that before the correction of the GPIO block's
> window this particular IRQ would be #208 in &pmicintc and #208 in
> &pm8058_gpio. After the correction of the window the IRQ is #208 in
> &pmicintc and #17 in &pm8058_gpio.
>
> As such, using #208 from &pmicintc would make this work through the
> correction of the GPIO driver. Perhaps I'm wrong about this?
No that is exactly what I mean. I just mean I should not use
the pm8058_gpio as interrupt parent at all for now.
(You will see in my patch set, cooking it.)
>> What needs to happen is for the SSBI and SPMI GPIO to use a
>> hierarchical irqdomain so their GPIO local line offset and hwirq
>> are the same. Then we can reference the GPIO IRQ lines directly
>> in a correct manner.
>
> Right. Do you have any example of drivers getting this right? I did take
> a quick look but didn't find one.
It seems drivers/gpio/gpio-xgene-sb.c is doing something like
what we want. See for example how it picks out the parent domain
and hangs a new domain off it.
If possible, I would like to add infrastructure for this to gpiolib,
if it can be made generic and make sense.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface
From: Neil Armstrong @ 2016-11-03 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102222050.GA32189@e106835-lin.cambridge.arm.com>
On 11/02/2016 11:20 PM, Sudeep Holla wrote:
> On Sat, Oct 29, 2016 at 11:39:05AM -0700, Olof Johansson wrote:
>
> I will rework the patches to address the concerns as I too did share same
> concern.
>
>
> Hi Neil,
>
> You may need to rework the DTS files based on that, please be aware of
> that and make the necessary changes.
Hi,
I will post the necessary changes since kevin already applied the previous patches.
Thanks,
Neil
>
> --
> Regards,
> Sudeep
>
^ permalink raw reply
* [PATCH v2 0/6] STM32F4 Add RTC & QSPI clocks
From: Alexandre Torgue @ 2016-11-03 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476436699-21879-1-git-send-email-gabriel.fernandez@st.com>
Hi Gabriel,
On 10/14/2016 11:18 AM, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> v2:
> - rename compatible property "st,stm32f46xx-rcc" into "st,stm32f469-rcc"
> - cosmetic: remove bad copy/paste
>
> This patch-set introduce RTC and QSPI clocks for STM32F4 socs
> RTC clock has 3 parents clock oscillators (lsi/lse/hse_rtc)
>
> example to use rtc clock:
>
> rtc: rtc at 40002800 {
> compatible = "st,stm32-rtc";
> reg = <0x40002800 0x400>;
> ...
> clocks = <&rcc 1 CLK_RTC>;
>
> assigned-clocks = <&rcc 1 CLK_RTC>;
> assigned-clock-parents = <&rcc 1 CLK_LSE>;
> ...
> };
>
> Gabriel Fernandez (6):
> clk: stm32f4: Add LSI & LSE clocks
> ARM: dts: stm32f429: add LSI and LSE clocks
> arm: stmf32: Enable SYSCON
> clk: stm32f4: Add RTC clock
> clk: stm32f469: Add QSPI clock
> ARM: dts: stm32f429: Add QSPI clock
You sent a V3 without DT patches. Should I take DT patches from this V2
patchset ?
Regards
Alex
>
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 4 +-
> arch/arm/boot/dts/stm32f429.dtsi | 18 +
> arch/arm/boot/dts/stm32f469-disco.dts | 4 +
> arch/arm/configs/stm32_defconfig | 1 +
> drivers/clk/clk-stm32f4.c | 442 ++++++++++++++++++++-
> 5 files changed, 447 insertions(+), 22 deletions(-)
>
^ permalink raw reply
* [PATCH] clk: rockchip: fix some clocks' name to be more standard style
From: Shawn Lin @ 2016-11-03 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478070296-23080-1-git-send-email-jay.xu@rock-chips.com>
On 2016/11/2 15:04, Jianqun Xu wrote:
> Fix aclk_emmcgrf to aclk_emmc_grf, and fix aclk_emmccore to be
> aclk_emmc_core.
>
What is the standard style should be?
TRM uses aclk_emmccore but not aclk_emmc_core, so should it be more
standrad to keep it as-is?
> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> ---
> drivers/clk/rockchip/clk-rk3399.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
> index 2c7cba7..b3df2c6 100644
> --- a/drivers/clk/rockchip/clk-rk3399.c
> +++ b/drivers/clk/rockchip/clk-rk3399.c
> @@ -935,11 +935,11 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = {
> RK3399_CLKGATE_CON(6), 13, GFLAGS),
> COMPOSITE_NOGATE(ACLK_EMMC, "aclk_emmc", mux_aclk_emmc_p, CLK_IGNORE_UNUSED,
> RK3399_CLKSEL_CON(21), 7, 1, MFLAGS, 0, 5, DFLAGS),
> - GATE(ACLK_EMMC_CORE, "aclk_emmccore", "aclk_emmc", CLK_IGNORE_UNUSED,
> + GATE(ACLK_EMMC_CORE, "aclk_emmc_core", "aclk_emmc", CLK_IGNORE_UNUSED,
> RK3399_CLKGATE_CON(32), 8, GFLAGS),
> GATE(ACLK_EMMC_NOC, "aclk_emmc_noc", "aclk_emmc", CLK_IGNORE_UNUSED,
> RK3399_CLKGATE_CON(32), 9, GFLAGS),
> - GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", CLK_IGNORE_UNUSED,
> + GATE(ACLK_EMMC_GRF, "aclk_emmc_grf", "aclk_emmc", CLK_IGNORE_UNUSED,
> RK3399_CLKGATE_CON(32), 10, GFLAGS),
>
> /* perilp0 */
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH v2 0/6] STM32F4 Add RTC & QSPI clocks
From: Gabriel Fernandez @ 2016-11-03 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68855ca8-a74f-7c76-342f-de0aeec51ca1@st.com>
Hi Alexandre,
On 11/03/2016 09:52 AM, Alexandre Torgue wrote:
> Hi Gabriel,
>
> On 10/14/2016 11:18 AM, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> v2:
>> - rename compatible property "st,stm32f46xx-rcc" into
>> "st,stm32f469-rcc"
>> - cosmetic: remove bad copy/paste
>>
>> This patch-set introduce RTC and QSPI clocks for STM32F4 socs
>> RTC clock has 3 parents clock oscillators (lsi/lse/hse_rtc)
>>
>> example to use rtc clock:
>>
>> rtc: rtc at 40002800 {
>> compatible = "st,stm32-rtc";
>> reg = <0x40002800 0x400>;
>> ...
>> clocks = <&rcc 1 CLK_RTC>;
>>
>> assigned-clocks = <&rcc 1 CLK_RTC>;
>> assigned-clock-parents = <&rcc 1 CLK_LSE>;
>> ...
>> };
>>
>> Gabriel Fernandez (6):
>> clk: stm32f4: Add LSI & LSE clocks
>> ARM: dts: stm32f429: add LSI and LSE clocks
>> arm: stmf32: Enable SYSCON
>> clk: stm32f4: Add RTC clock
>> clk: stm32f469: Add QSPI clock
>> ARM: dts: stm32f429: Add QSPI clock
>
> You sent a V3 without DT patches. Should I take DT patches from this
> V2 patchset ?
>
> Regards
> Alex
>
Yes, no problem
Thanks !
BR.
Gabriel
>
>>
>> .../devicetree/bindings/clock/st,stm32-rcc.txt | 4 +-
>> arch/arm/boot/dts/stm32f429.dtsi | 18 +
>> arch/arm/boot/dts/stm32f469-disco.dts | 4 +
>> arch/arm/configs/stm32_defconfig | 1 +
>> drivers/clk/clk-stm32f4.c | 442
>> ++++++++++++++++++++-
>> 5 files changed, 447 insertions(+), 22 deletions(-)
>>
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-03 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031084233.GS1041@n2100.armlinux.org.uk>
Hi Russell,
On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > The first one is that this overscanning should be reported by the
> > connector I guess? but this is really TV specific, so we need one way
> > to let the user tell how the image is displayed on its side, and we
> > cannot really autodetect it, and this needs to be done at runtime so
> > that we can present some shiny interface to let it select which
> > overscan ratio works for him/her.
>
> See xbmc... they go through a nice shiny setup which includes adjusting
> the visible area. From what I remember, it has pointers on each corner
> which you can adjust to be just visible on the screen, so xbmc knows
> how much overscan there is, and xbmc itself reduces down to the user
> set size.
Yes. And that is an XBMC only solution, that doesn't work with the
fbdev emulation and is probably doing an additional composition to
scale down and center their frames through OpenGL.
We might not have a GPU in the system, and we might not even have an
entire graphic stack on top either, so I don't think fixing at the
user-space level is a good option (especially since we already have an
overscan property in DRM).
> > The second one is that we still need to expose the reduced modes to
> > userspace, and not only the displayed size, so that the applications
> > know what they must draw on. But I guess this could be adjusted by the
> > core too.
> >
> > In order to work consistently, I think all planes should be adjusted
> > that way, so that relative coordinates are from the primary plane
> > origin, and not the display origin. But that could be adjusted too by
> > the core I guess.
>
> I'm not sure about that - we want the graphics to be visible, but that
> may not be appropriate for an video overlay frame. It's quite common
> for (eg) broadcast video to contain dead pixels or other artifacts on
> the right hand side, and the broadcast video expects overscan to be
> present.
>
> I know this because I have run my TV with overscan disabled, even for
> broadcast TV.
I know, but on this particular hardware, composite really is just
another video output. There's not even a TV receiver in it, so I don't
think we have to worry about it.
> > The fourth one being the major one. Every time I raised the issue on
> > IRC, the answer basically was "we don't care about analog", so I'm a
> > bit pessimistic about whether dealing with this in the core would be
> > accepted, hence why I chose to deal with this at the driver level.
>
> Yea, that's quite sad, "analog" has become a dirty word, but really
> this has nothing to do with "analog" at all - there are LCD TVs (and
> some monitors) out there which take HDMI signals but refuse to
> disable overscan no matter what you do to them if you provide them
> with a "broadcast" mode - so the analog excuse is very poor.
I'd agree with you, but I was also told to not turn that into a
generic code and deal with that in my driver.
Do you have any suggestions?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/29a096c4/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] ARM64: meson-gxbb: SCPI Fixup
From: Neil Armstrong @ 2016-11-03 9:11 UTC (permalink / raw)
To: linux-arm-kernel
This patchset updates the GXBB dtsi and the ARM64 defconfig in order
to make SCPI work following the Legacy SCPI rework from Sudeep Hola at [1].
The rework introduced a generic "arm,legacy-scpi" compatible string.
The second patch enables the necessary Platform MHU in defconfig.
[1] http://lkml.kernel.org/r/1478148731-11712-1-git-send-email-sudeep.holla at arm.com
Neil Armstrong (2):
ARM64: dts: meson-gxbb: Add generic legacy scpi compatible
ARM64: configs: Add Platform MHU in defconfig
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
arch/arm64/configs/defconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: meson-gxbb: Add generic legacy scpi compatible
From: Neil Armstrong @ 2016-11-03 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164284-24958-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 2d69a3b..5394657 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -75,7 +75,7 @@
};
scpi {
- compatible = "amlogic,meson-gxbb-scpi";
+ compatible = "amlogic,meson-gxbb-scpi", "arm,legacy-scpi";
mboxes = <&mailbox 1 &mailbox 2>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM64: configs: Add Platform MHU in defconfig
From: Neil Armstrong @ 2016-11-03 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164284-24958-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dab2cb0..6631bda 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -394,6 +394,7 @@ CONFIG_MSM_MMCC_8996=y
CONFIG_HWSPINLOCK_QCOM=y
CONFIG_MAILBOX=y
CONFIG_ARM_MHU=y
+CONFIG_PLATFORM_MHU=y
CONFIG_HI6220_MBOX=y
CONFIG_ARM_SMMU=y
CONFIG_QCOM_SMEM=y
--
1.9.1
^ permalink raw reply related
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Neil Armstrong @ 2016-11-03 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-1-git-send-email-sudeep.holla@arm.com>
On 11/03/2016 05:52 AM, Sudeep Holla wrote:
> Hi,
>
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
>
> --
> Regards,
> Sudeep
>
> [1] http://www.spinics.net/lists/arm-kernel/msg534999.html
>
> Neil Armstrong (4):
> firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
> firmware: arm_scpi: add alternative legacy structures, functions and
> macros
> firmware: arm_scpi: allow firmware with get_capabilities not
> implemented
> Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
>
> Sudeep Holla (4):
> firmware: arm_scpi: add command indirection to support legacy commands
> Documentation: bindings: decouple juno specific details from generic
> binding
> Documentation: bindings: add compatible specific to legacy SCPI
> protocol
> firmware: arm_scpi: add support for legacy SCPI compatible
>
> .../devicetree/bindings/arm/amlogic,scpi.txt | 20 ++
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 24 +-
> .../devicetree/bindings/arm/juno,scpi.txt | 26 ++
> drivers/firmware/arm_scpi.c | 276 ++++++++++++++++++---
> 4 files changed, 300 insertions(+), 46 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
> create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
>
Hi Sudeep,
Ok for me, I submitted the fix for the GXBB dtsi.
Neil
^ permalink raw reply
* [PATCH 1/3] ARM: dts: rename MSM8660/APQ8060 pmicintc to pm8058
From: Linus Walleij @ 2016-11-03 9:13 UTC (permalink / raw)
To: linux-arm-kernel
The name "pmicintc" is ambiguous: there is a second power
management IC named PM8901 on these systems, and it is also
an interrupt controller. To make things clear, just name the
node alias "pm8058", this in unambigous and has all information
we need.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660-surf.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660.dtsi | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4b8872cc8bf9..4a532ddab53a 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -412,7 +412,7 @@
* The second interrupt is the PME interrupt
* for network wakeup, connected to the TLMM.
*/
- interrupts-extended = <&pmicintc 198 IRQ_TYPE_EDGE_FALLING>,
+ interrupts-extended = <&pm8058 198 IRQ_TYPE_EDGE_FALLING>,
<&tlmm 29 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
vdd33a-supply = <&dragon_veth>;
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 23de764558ab..1adc04978a47 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -48,7 +48,7 @@
};
};
-&pmicintc {
+&pm8058 {
keypad at 148 {
linux,keymap = <
MATRIX_KEY(0, 0, KEY_FN_F1)
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
index 4d828f810746..91c9a62ae725 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -163,7 +163,7 @@
reg = <0x500000 0x1000>;
qcom,controller-type = "pmic-arbiter";
- pmicintc: pmic at 0 {
+ pm8058: pmic at 0 {
compatible = "qcom,pm8058";
interrupt-parent = <&tlmm>;
interrupts = <88 8>;
@@ -176,7 +176,7 @@
compatible = "qcom,pm8058-gpio",
"qcom,ssbi-gpio";
reg = <0x150>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <192 IRQ_TYPE_NONE>,
<193 IRQ_TYPE_NONE>,
<194 IRQ_TYPE_NONE>,
@@ -232,7 +232,7 @@
reg = <0x50>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts =
<128 IRQ_TYPE_NONE>,
<129 IRQ_TYPE_NONE>,
@@ -251,7 +251,7 @@
pwrkey at 1c {
compatible = "qcom,pm8058-pwrkey";
reg = <0x1c>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <50 1>, <51 1>;
debounce = <15625>;
pull-up;
@@ -260,7 +260,7 @@
keypad at 148 {
compatible = "qcom,pm8058-keypad";
reg = <0x148>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <74 1>, <75 1>;
debounce = <15>;
scan-delay = <32>;
@@ -270,7 +270,7 @@
rtc at 1e8 {
compatible = "qcom,pm8058-rtc";
reg = <0x1e8>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <39 1>;
allow-set-time;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: reference PM8058 as IRQ parent
From: Linus Walleij @ 2016-11-03 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164390-21613-1-git-send-email-linus.walleij@linaro.org>
Some nodes are referencing the pm8058_gpio as IRQ parent, but
the HW IRQ offset they are supplying is actually that for the
parent to that controller: the PM8058 itself. Since that is the
proper parent, reference it directly.
We can switch this to the pm8058_gpio and the proper offset
once we have fixed the SSBI GPIO driver to properly deal with
the hierarchical IRQ domain and get proper local offset
translation.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4a532ddab53a..ea660ffa03ea 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -369,8 +369,8 @@
ak8975 at 0c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
- /* GPIO33 has interrupt 224 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO33 has interrupt 224 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <224 IRQ_TYPE_EDGE_RISING>;
pinctrl-names = "default";
pinctrl-0 = <&dragon_ak8975_gpios>;
@@ -380,8 +380,8 @@
bmp085 at 77 {
compatible = "bosch,bmp085";
reg = <0x77>;
- /* GPIO16 has interrupt 207 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO16 has interrupt 207 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <207 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 86 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Linus Walleij @ 2016-11-03 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164390-21613-1-git-send-email-linus.walleij@linaro.org>
This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
MPU-3050 and appear as a subdevice beyond it. We set up the
required GPIO and interrupt lines to make the devices work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move the interrupt to the pm8058 alias to reflect the two patches
properly specifying the PMIC as interrupt parent.
ChangeLog v1->v2:
- Use the new I2C mux gate bindings from Peter Rosin (merged to
the I2C subsystem)
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index ea660ffa03ea..c1b99c9cb318 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -220,6 +220,14 @@
function = "ebi2";
};
};
+
+ /* Interrupt line for the KXSD9 accelerometer */
+ dragon_kxsd9_gpios: kxsd9 {
+ irq {
+ pins = "gpio57"; /* IRQ line */
+ bias-pull-up;
+ };
+ };
};
qcom,ssbi at 500000 {
@@ -272,6 +280,15 @@
power-source = <PM8058_GPIO_S3>;
};
};
+ dragon_mpu3050_gpios: mpu3050-gpios {
+ pinconf {
+ pins = "gpio17";
+ function = "normal";
+ input-enable;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
dragon_sdcc3_gpios: sdcc3-gpios {
pinconf {
pins = "gpio22";
@@ -389,6 +406,42 @@
vddd-supply = <&pm8058_lvs0>; // 1.8V
vdda-supply = <&pm8058_l14>; // 2.85V
};
+ mpu3050 at 68 {
+ compatible = "invensense,mpu3050";
+ reg = <0x68>;
+ /*
+ * GPIO17 has interrupt 208 on the
+ * PM8058, it is pulled high by a 10k
+ * resistor to VLOGIC so needs to be
+ * active low/falling edge.
+ */
+ interrupt-parent = <&pm8058>;
+ interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_mpu3050_gpios>;
+ vlogic-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+
+ /*
+ * The MPU-3050 acts as a hub for the
+ * accelerometer.
+ */
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ kxsd9 at 18 {
+ compatible = "kionix,kxsd9";
+ reg = <0x18>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_kxsd9_gpios>;
+ iovdd-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+ };
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] video: ARM CLCD: fix Vexpress regression
From: Linus Walleij @ 2016-11-03 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f95e05ef-e8e0-c5f4-9635-ae392c1812a3@ti.com>
On Wed, Nov 2, 2016 at 9:34 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 20/10/16 09:46, Linus Walleij wrote:
>> The CLCD does not come up on Versatile Express as it does not
>> (currently) have a syscon node for controlling the block apart
>> from the CLCD itself. Make sure the .init() function can bail
>> out without an error making it probe again.
>>
>> Reported-by: Amit Pundir <amit.pundir@linaro.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> drivers/video/fbdev/amba-clcd-versatile.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
>> index 19ad8645d93c..d909b7dda14d 100644
>> --- a/drivers/video/fbdev/amba-clcd-versatile.c
>> +++ b/drivers/video/fbdev/amba-clcd-versatile.c
>> @@ -527,7 +527,8 @@ int versatile_clcd_init_panel(struct clcd_fb *fb,
>> &clcd_id);
>> if (!np) {
>> dev_err(dev, "no Versatile syscon node\n");
>> - return -ENODEV;
>> + /* Vexpress does not have this */
>> + return 0;
>> }
>> versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
>
> Actually, the above doesn't look correct. If this is not an error, then
> the driver shouldn't print an error.
>
> Shall I just remove the print?
You're right, sorry for not thinking deeper :(
Just cut the print.
Thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Russell King - ARM Linux @ 2016-11-03 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103090106.dq2bn4z7m2hzhi53@lukather>
On Thu, Nov 03, 2016 at 10:01:06AM +0100, Maxime Ripard wrote:
> Hi Russell,
>
> On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote:
> > On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > > The first one is that this overscanning should be reported by the
> > > connector I guess? but this is really TV specific, so we need one way
> > > to let the user tell how the image is displayed on its side, and we
> > > cannot really autodetect it, and this needs to be done at runtime so
> > > that we can present some shiny interface to let it select which
> > > overscan ratio works for him/her.
> >
> > See xbmc... they go through a nice shiny setup which includes adjusting
> > the visible area. From what I remember, it has pointers on each corner
> > which you can adjust to be just visible on the screen, so xbmc knows
> > how much overscan there is, and xbmc itself reduces down to the user
> > set size.
I was replying to your comment "so we need one way to let the user tell
how the image is displayed".
> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.
Well, it will have to be doing a scaling step anyway. If the video
frame is a different size to the active area, scaling is required
no matter what. A 576p SD image needs to be scaled up, and a 1080p
image would need to be scaled down for a 1080p overscanned display
with a reduced active area to counter the overscanning - no matter
how you do it.
For graphics, userspace could add mode(s) with increased porches and
reduced active area itself to achieve an underscanned display on a
timing which the display device always overscans - there's no need to
do that in the kernel, all the APIs are there to be able to do it
already.
That means your framebuffer will be smaller, but that's the case
anyway.
> > > The second one is that we still need to expose the reduced modes to
> > > userspace, and not only the displayed size, so that the applications
> > > know what they must draw on. But I guess this could be adjusted by the
> > > core too.
> > >
> > > In order to work consistently, I think all planes should be adjusted
> > > that way, so that relative coordinates are from the primary plane
> > > origin, and not the display origin. But that could be adjusted too by
> > > the core I guess.
> >
> > I'm not sure about that - we want the graphics to be visible, but that
> > may not be appropriate for an video overlay frame. It's quite common
> > for (eg) broadcast video to contain dead pixels or other artifacts on
> > the right hand side, and the broadcast video expects overscan to be
> > present.
> >
> > I know this because I have run my TV with overscan disabled, even for
> > broadcast TV.
>
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.
Whether or not there's a TV receiver is irrelevant - if you can decode
broadcast video, then you run into the problem. For example, if you
plug in a USB DVB stick, stream it across the network, etc.
Remember, you're proposing a generic solution, so making arguments
about things that are not possible with your specific hardware isn't
really that relevant to a generic solution.
So, I may want my graphics to appear on an overscanned display such
that I can see the borders, but I may want the overlaid video to use
the full active area (including overscan) to hide some of the broadcast
mess at the edges of the screen.
> > Yea, that's quite sad, "analog" has become a dirty word, but really
> > this has nothing to do with "analog" at all - there are LCD TVs (and
> > some monitors) out there which take HDMI signals but refuse to
> > disable overscan no matter what you do to them if you provide them
> > with a "broadcast" mode - so the analog excuse is very poor.
>
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.
I guess whoever told you that was wrong. I used to have a cheap TV
here which took HDMI, and always overscans broadcast modes, and
underscans PC modes. No amount of fiddling with various settings
(either in the TV or AVI frames) changes that.
I've run into that with a _monitor_ that Andrew Hutton has, which has
a HDMI input - exactly the same thing - 1080p, 720p etc are all
unconditionally overscanned, 1024x768 etc are all unconditionally
underscanned and there's nothing that can be done to change it.
The problem is that TVs are at liberty to have this behaviour, so
the overscaned problem is always going to be there, and each driver
should not be dealing with it in their own specific ways.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Pavel Machek @ 2016-11-03 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019131145.GA11036@leverpostej>
On Wed 2016-10-19 14:11:45, Mark Rutland wrote:
> On Wed, Oct 19, 2016 at 11:42:27AM +0200, Pavel Machek wrote:
> > On Tue 2016-10-18 11:45:39, Mark Rutland wrote:
>
> > Either the lowlevel suspend code is stable and bug free, and then
> > having that code is not a problem.
>
> This ignores the cost of maintaining that code. Kernel APIs change over
> time, and no code is ever completely stable, even if at one point in
> time it happens to be bug-free.
Well, kernel interfaces only change when there's good reason for a
change, and if you force stable binary interface to external
component, and there _is_ need for a change, we are all screwed.
> > BSD is better than closed source, but it also means that you will not
> > get the sources from your hw vendor.
>
> That depends on your hardware vendor, as always. There are a number of
> platform ports in the upstream ATF repo.
>
> It's also worth considering that a number of 32-bit arm parts require
> closed firmware (as far as I can tell, including the N900).
Yeah, but we are trying to remove closed firmware. Don't make people
add more of it...
> > Being separate module means it will be hard to debug, in area where
> > debugging is already pretty hard.
>
> It can be harder, yes. There are also benefits, given the same code can
> be tested on a variety of platforms.
What benefits? You are able to share code between platforms in kernel,
too.
> > Can it do advanced stuff like deep powersaving on N900 idle?
>
> Sorry, I don't know precisely what you're referring to.
>
> It can do things like shutting down entire CPU clusters (and IIRC
> associated interconnect) when all relevant CPUs are idle, if that's what
> you mean.
I mean equivalent power savings between idle system and system in
s2ram.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/b3b419d1/attachment.sig>
^ permalink raw reply
* [PATCH V3 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table
From: Jon Hunter @ 2016-11-03 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477576872-2665-2-git-send-email-mirza.krak@gmail.com>
Hi Mirza,
On 27/10/16 15:01, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak@gmail.com>
>
> Add TEGRA20_CLK_NOR to init table and set default rate to 92 MHz which
> is max rate.
>
> The maximum rate value of 92 MHz is pulled from the downstream L4T
> kernel.
Thanks for adding this. I assume that this is from an L4T r16 release
with a v3.1 kernel. I had a quick poke through the kernel sources for
v3.1 but was unable to see where this is set. Obviously v3.1 did not
have CCF and so everything seems to be in the arch/arm/mach-tegra
directory for setting up clocks. Can you point me to the appropriate
sources so I can ACK this?
Cheers
Jon
--
nvpublic
^ 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