* Re: [PATCH 1/5] clk: sun6i: Protect CPU clock
From: Russell King - ARM Linux @ 2014-02-25 0:01 UTC (permalink / raw)
To: Emilio López
Cc: Maxime Ripard, devicetree-u79uwXL29TY76Z2rM5mHXA, Mike Turquette,
Vinod Koul, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dmaengine-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <530BD804.5090806-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>
Hi Emilio.
On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio López wrote:
> Why is this so? Can't a clock be left enabled while nobody has a
> reference to it? I have looked around in Documentation/ (rather quickly
> I must say) and have not found any explicit mention that it is required
> to keep a reference to the clock while it's enabled. I'd appreciate it
> if you could explain this a bit more verbosely or point me to the
> relevant documents.
First up, if you have a requirement that a clock be enabled, then is it
not unreasonable to ensure that the clock is referenced?
Secondly, what if we have code which scans the clocks in the system,
shutting down those leaf clocks which appear to be unreferenced?
Thirdly, the API (as I designed it) says so:
/**
* clk_put - "free" the clock source
* @clk: clock source
*
* Note: drivers must ensure that all clk_enable calls made on this
* clock source are balanced by clk_disable calls prior to calling
* this function.
*
* clk_put should not be called from within interrupt context.
*/
void clk_put(struct clk *clk);
which has been there since the API was first created - it's part of the
contract between drivers using the API and implementers creating something
which conforms to the API - which today means CCF.
The intention here is that while there are any users holding a clk_get()
reference on a clock, the clock is assumed to be required for some
device, and the struct clk may not be kfree'd, nor may its state be
changed in an unpredictable way to those drivers holding a reference
to it.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [Patch v7 2/2] dmaengine: add Qualcomm BAM dma driver
From: Felipe Balbi @ 2014-02-25 0:09 UTC (permalink / raw)
To: Andy Gross
Cc: Vinod Koul, Dan Williams, dmaengine, linux-kernel,
linux-arm-kernel, linux-arm-msm, devicetree
In-Reply-To: <1393283500-18599-3-git-send-email-agross@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi,
On Mon, Feb 24, 2014 at 05:11:40PM -0600, Andy Gross wrote:
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 605b016..f87cef9 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -401,4 +401,13 @@ config DMATEST
> config DMA_ENGINE_RAID
> bool
>
> +config QCOM_BAM_DMA
> + tristate "QCOM BAM DMA support"
> + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
do you really want to make it depend on ARM even when COMPILE_TEST=y ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] clk: sun6i: Protect CPU clock
From: Emilio López @ 2014-02-25 0:30 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Maxime Ripard, devicetree-u79uwXL29TY76Z2rM5mHXA, Mike Turquette,
Vinod Koul, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dmaengine-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
rjw-KKrjLPT3xs0
In-Reply-To: <20140225000154.GR21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Hi Russell,
El 24/02/14 21:01, Russell King - ARM Linux escribió:
> Hi Emilio.
>
> On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio López wrote:
>> Why is this so? Can't a clock be left enabled while nobody has a
>> reference to it? I have looked around in Documentation/ (rather quickly
>> I must say) and have not found any explicit mention that it is required
>> to keep a reference to the clock while it's enabled. I'd appreciate it
>> if you could explain this a bit more verbosely or point me to the
>> relevant documents.
>
> First up, if you have a requirement that a clock be enabled, then is it
> not unreasonable to ensure that the clock is referenced?
I was under the impression that the reference count was orthogonal to
the clock status, but after getting that clarified, I can see your point.
> Secondly, what if we have code which scans the clocks in the system,
> shutting down those leaf clocks which appear to be unreferenced?
Indeed, that would break things.
> Thirdly, the API (as I designed it) says so:
>
> /**
> * clk_put - "free" the clock source
> * @clk: clock source
> *
> * Note: drivers must ensure that all clk_enable calls made on this
> * clock source are balanced by clk_disable calls prior to calling
> * this function.
> *
> * clk_put should not be called from within interrupt context.
> */
> void clk_put(struct clk *clk);
>
> which has been there since the API was first created - it's part of the
> contract between drivers using the API and implementers creating something
> which conforms to the API - which today means CCF.
That's enough of a reason on its own :) I should have checked clk.h
> The intention here is that while there are any users holding a clk_get()
> reference on a clock, the clock is assumed to be required for some
> device, and the struct clk may not be kfree'd, nor may its state be
> changed in an unpredictable way to those drivers holding a reference
> to it.
I understand now, thanks for the insight. I'll talk with Maxime and get
this sorted out.
As a side note, should drivers/base/power/clock_ops.c be fixed too? I
have added Rafael to Cc.
Cheers,
Emilio
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH 1/1] ARM: Exynos: Add generic compatible string
From: Kukjin Kim @ 2014-02-25 0:35 UTC (permalink / raw)
To: Sachin Kamat
Cc: Tomasz Figa, Arnd Bergmann, linux-arm-kernel, Mark Rutland,
devicetree@vger.kernel.org, Kukjin Kim, Ian Campbell, Rob Herring,
Grant Likely, linux-samsung-soc, Olof Johansson
In-Reply-To: <CAK9yfHxiHkrf1xmSFbfoKqFFSCU6w4QqwPnQNdv1m1PGtrwsLQ@mail.gmail.com>
On 02/24/14 21:03, Sachin Kamat wrote:
> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com> wrote:
>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>
>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>
>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>
>>>>>
>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>> ahead with the
>>>>>> following steps as an initial approach:
>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>> mach-exynos-dt.c.
>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
Well, I think, we need to consider to use compatible string
"samsung,exynos" again because "exynos" name can be used on ARMv8 as
well and I don't want to say that generic/common something is always
good. So IMHO still using exynos4 and exynos5 would be better.
>>>>>> 3. Append this to the compatible property list for existing boards.
>>>>>>
>>>>>> If this plan looks OK, I can send across patches doing this.
>>>>>>
>>>>>
>>>>> Looks good. I would also merge common.c with this resulting
>>>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>>>
>>>>
>>>> Sounds good. While the naming is not important, I would just call the
>>>> file 'exynos.c', in line with some of the other platforms we have.
>>>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>>>
>>>> Alternatively, you could merge it all into common.c.
>>>
>>>
>>> exynos.c sounds good to me.
>>
Well, let me see common.c and mach-exynos.c, one is for SoC specific
stuff and the other is for Board specific so I think, keeping current
file would be good, we can change the file name mach-exynos.c or
board-exynos.c though.
Thanks,
Kukjin
>>
>> One minor thing. It might be a good idea to base on top of my PM
>> consolidation part 2 series, to avoid merge conflicts:
>>
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/299340
>>
>> It should hit Kgene's tree this weekend.
>
> Sure.
>
^ permalink raw reply
* Re: [PATCHv1 1/6] HSI: add Device Tree support for HSI clients
From: Rob Herring @ 2014-02-25 0:47 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Linus Walleij, Shubhrajyoti Datta,
Carlos Chinea, Tony Lindgren, Grant Likely, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Rob Landley, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap, Pali Rohár,
Ивайло Димитров,
Joni Lapilainen, Aaro Koskinen
In-Reply-To: <1393199401-27197-2-git-send-email-sre@debian.org>
On Sun, Feb 23, 2014 at 5:49 PM, Sebastian Reichel <sre@debian.org> wrote:
> Add new method hsi_add_clients_from_dt, which can be used
> to initialize HSI clients from a device tree node.
>
> The patch also documents the DT binding for trivial HSI
> clients.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> .../devicetree/bindings/hsi/trivial-devices.txt | 36 +++++++++++
> drivers/hsi/hsi.c | 70 +++++++++++++++++++++-
> include/dt-bindings/hsi/hsi.h | 17 ++++++
> include/linux/hsi/hsi.h | 2 +
> 4 files changed, 124 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/hsi/trivial-devices.txt
> create mode 100644 include/dt-bindings/hsi/hsi.h
>
> diff --git a/Documentation/devicetree/bindings/hsi/trivial-devices.txt b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> new file mode 100644
> index 0000000..1ace14a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> @@ -0,0 +1,36 @@
> +This is a list of trivial hsi client devices that have simple
> +device tree bindings, consisting only of a compatible field
> +and the optional hsi configuration.
> +
> +If a device needs more specific bindings, such as properties to
> +describe some aspect of it, there needs to be a specific binding
> +document for it just like any other devices.
> +
> +Optional HSI configuration properties:
> +
> +- hsi,mode Bit transmission mode (STREAM or FRAME)
hsi is not a vendor prefix, so all these properties should be hsi-*.
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
> +- hsi,channels Number of channels to use [1..16]
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> +- hsi,speed Max bit transmission speed (Kbit/s)
Include the units in the prop name: hsi-speed-kbps
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> +- hsi,flow RX flow type (SYNCHRONIZED or PIPELINE)
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
> +- hsi,arb_mode Arbitration mode for TX frame (Round robin, priority)
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
> +
> +This is the list of trivial client devices:
> +
> +Compatible Description
> +========== =============
> +hsi-char HSI character device
I've gotten this far and still have no idea what HSI is.
Rob
^ permalink raw reply
* Re: [PATCH 1/1] ARM: Exynos: Add generic compatible string
From: Tomasz Figa @ 2014-02-25 0:52 UTC (permalink / raw)
To: Kukjin Kim, Sachin Kamat
Cc: Tomasz Figa, Arnd Bergmann, linux-arm-kernel, Mark Rutland,
devicetree@vger.kernel.org, Ian Campbell, Rob Herring,
Grant Likely, linux-samsung-soc, Olof Johansson
In-Reply-To: <530BE557.20106@samsung.com>
On 25.02.2014 01:35, Kukjin Kim wrote:
> On 02/24/14 21:03, Sachin Kamat wrote:
>> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com> wrote:
>>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>>
>>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>>
>>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>>
>>>>>>
>>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>>> ahead with the
>>>>>>> following steps as an initial approach:
>>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>>> mach-exynos-dt.c.
>>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>
> Well, I think, we need to consider to use compatible string
> "samsung,exynos" again because "exynos" name can be used on ARMv8 as
> well and I don't want to say that generic/common something is always
> good. So IMHO still using exynos4 and exynos5 would be better.
You can create a new compatible string (e.g. "samsung,exynos-armv8") for
ARMv8 Exynos if support for one in mainline shows up and/or simply use
another name for ARMv7 Exynos (e.g. "samsung,exynos-armv7").
>>>>>>> 3. Append this to the compatible property list for existing boards.
>>>>>>>
>>>>>>> If this plan looks OK, I can send across patches doing this.
>>>>>>>
>>>>>>
>>>>>> Looks good. I would also merge common.c with this resulting
>>>>>> mach-exynos-dt.c, as it would be the only user of the code there.
>>>>>
>>>>>
>>>>> Sounds good. While the naming is not important, I would just call the
>>>>> file 'exynos.c', in line with some of the other platforms we have.
>>>>> Both the 'mach-' and the '-dt' part of the file name are redundant.
>>>>>
>>>>> Alternatively, you could merge it all into common.c.
>>>>
>>>>
>>>> exynos.c sounds good to me.
>>>
>
> Well, let me see common.c and mach-exynos.c, one is for SoC specific
> stuff and the other is for Board specific so I think, keeping current
> file would be good, we can change the file name mach-exynos.c or
> board-exynos.c though.
There is no board specific stuff in mach-exynos/ with DT, so there is no
need to keep those file separate, especially when stuff from common.c is
constantly being (re)moved.
Also I'd rather stick to what other platforms use, which would be
exynos.c (like tegra.c), as Arnd proposed.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 1/1] ARM: Exynos: Add generic compatible string
From: Kukjin Kim @ 2014-02-25 1:00 UTC (permalink / raw)
To: Tomasz Figa
Cc: Kukjin Kim, Sachin Kamat, Mark Rutland,
devicetree@vger.kernel.org, linux-samsung-soc, Arnd Bergmann,
Ian Campbell, Tomasz Figa, Grant Likely, Rob Herring,
Olof Johansson, linux-arm-kernel
In-Reply-To: <530BE93F.2070904@gmail.com>
On 02/25/14 09:52, Tomasz Figa wrote:
> On 25.02.2014 01:35, Kukjin Kim wrote:
[...]
>> Well, let me see common.c and mach-exynos.c, one is for SoC specific
>> stuff and the other is for Board specific so I think, keeping current
>> file would be good, we can change the file name mach-exynos.c or
>> board-exynos.c though.
>
> There is no board specific stuff in mach-exynos/ with DT, so there is no
> need to keep those file separate, especially when stuff from common.c is
> constantly being (re)moved.
>
OK.
> Also I'd rather stick to what other platforms use, which would be
> exynos.c (like tegra.c), as Arnd proposed.
>
agreed. OK.
- Kukjin
^ permalink raw reply
* Re: [PATCH v13 2/3] ata: Add APM X-Gene SoC AHCI SATA host controller driver
From: Tejun Heo @ 2014-02-25 1:40 UTC (permalink / raw)
To: Loc Ho
Cc: Olof Johansson, Arnd Bergmann, Linux SCSI List,
linux-ide@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Don Dutile, Jon Masters,
patches@apm.com, Tuan Phan, Suman Tripathi
In-Reply-To: <CAPw-ZT=VHj+fO-7+G6Zdx+T+osJhXaR9AYHbx_TbWFWHBiDKYg@mail.gmail.com>
Hey,
On Mon, Feb 24, 2014 at 05:02:52PM -0800, Loc Ho wrote:
> The completion of the RAM removal from shutdown is quite fast. As per
> spec, the max time is 1ms but from the run-time code, it only take one
> (1us) or two (2us) read for this to completed. An 1 ms hard delay is more
> than 100 time slower. The code isn't that complex. If you strongly advise
> that I should remove the while loop and use 1 ms, then okay. Otherwise, I
> would prefer to keep the original code.
The code is rather silly because as it's written the delay may be upto
100ms. If it's sitting in the hot path, using things like
usleep_range() makes sense. In probe / shutdown paths, it's just an
unnecessary distraction. If the timeout is as short as 1ms, it
doesn't really matter whether the hardware can do it faster or not.
It's just irrelevant. Please just write simple code.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 1/2] ARM: shmobile: r8a7778/r8a7779 dtsi: Improve and correct HSPI bindings
From: Simon Horman @ 2014-02-25 1:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-spi, devicetree, linux-arm-kernel, linux-sh, linux-kernel,
Geert Uytterhoeven, Mark Brown
In-Reply-To: <20140224002837.GA3898@verge.net.au>
On Mon, Feb 24, 2014 at 09:28:40AM +0900, Simon Horman wrote:
> On Thu, Feb 20, 2014 at 03:57:18PM +0100, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> >
> > Binding documentation:
> > - Add future-proof "renesas,hspi-<soctype>" compatible values,
> > - Add "interrupt-parent", "#address-cells" and "#size-cells" properties,
> > - Add reference to pinctrl documentation,
> > - Add example bindings.
> >
> > r8a7778 and r8a7779 dtsi:
> > - Add "renesas,hspi-r8a7778" resp. "renesas,hspi-r8a7779" compatible
> > values,
> > - Correct reference to parent interrupt controller
> > (use "interrupt-parent" instead of "interrupt-controller"),
> > - Add missing "#address-cells" and "#size-cells" properties, which are
> > needed when populating the SPI buses.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> [HSPI/BockW]
> > Cc: Mark Brown <broonie@linaro.org>
> > ---
> > v2:
> > - Add Tested-by
> > - List full example compatible properties with soctypes instead of just
> > the soctypes, so checkpatch can validate DTSes.
>
> Thanks, I have queued this up.
I have dropped this patch and because it updates both driver documentation
and shmobile code.
Please split the patch into two, one to be taken by the driver maintainer,
Mark Brown. And one to be taken by me. Thanks
I have also dropped the second patch of this series, which depends on this
patch.
^ permalink raw reply
* RE: [PATCH v2 1/3] usb: chipidea: msm: Add device tree binding information
From: Peter Chen @ 2014-02-25 1:57 UTC (permalink / raw)
To: Ivan T. Ivanov, Courtney Cavin
Cc: richard.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
Greg Kroah-Hartman, David Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1393237096.6481.12.camel@iivanov-dev>
>
> Hi,
>
> On Wed, 2014-02-19 at 09:46 -0800, Courtney Cavin wrote:
> > On Wed, Feb 19, 2014 at 04:43:22PM +0100, Ivan T. Ivanov wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 2014-02-18 at 13:26 -0800, Courtney Cavin wrote:
> > > > On Tue, Feb 18, 2014 at 02:21:19PM +0100, Ivan T. Ivanov wrote:
> > > > > From: "Ivan T. Ivanov" <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
> > > > >
> > > > > Document device tree binding information as required by the
> > > > > Qualcomm USB controller.
> > > > >
> > > > > Signed-off-by: Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
> > > > > ---
> > > > > .../devicetree/bindings/usb/msm-hsusb.txt | 17
> +++++++++++++++++
> > > >
> > > > Although you mentioned to Josh that this is intended for "non-
> standard"
> > > > Chipidea properties, I don't see any other than requiring that
> 'dr_mode'
> > > > must be "peripheral". It would seem that this should all be
> > > > integrated into a ci3xxx.txt.
> > >
> > > Hm, there is no ci3xxx.txt. The closest match is ci-hdrc-imx.txt.
> > > So it could be ci-hdrc-qcom.txt or my preferred name qcom,ci-hdrc.txt?
> >
> > Sorry, I was referring to ci13xxx-imx.txt, which was apparently moved
> > to ci-hdrc-imx.txt. I was recommending to merge the two into one
> > 'ci13xxx.txt', as this binding seems to be a new compatible for the
> > same basic chip. Now perhaps 'ci-hdrc.txt'.
> >
> > Although I agree with Josh that this name should be changed, and I
> > think either of your two suggestions would be acceptable, I would like
> > to at least discuss the possibility of actually merging the two in
> > this series.
> >
> > Comments?
>
>
> iMX version have required and recommender properties which are not
> meaningful for QCOM variant. I will prefer separate file. It depends on
> Freescale engineers (now in Cc:)
>
>
Unlike dwc3, there is no common dts entry for chipidea core, every platform
uses its own dts to cover both common and platform-specific properties.
I also have plan to use dwc3 style way for dts, but msm platform has still
not used dts, I don't know how many msm platforms need to change, once
you finish transferring msm to dts, I will split common and platform specific
entry.
Peter
--
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 v11 09/15] usb: phy: Add set_wakeup API
From: Peter Chen @ 2014-02-25 2:03 UTC (permalink / raw)
To: Sergei Shtylyov, balbi@ti.com, shawn.guo@linaro.org,
robh+dt@kernel.org, grant.likely@linaro.org, pawel.moll@arm.com,
mark.rutland@arm.com
Cc: linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
festevam@gmail.com, marex@denx.de, kernel@pengutronix.de,
m.grzeschik@pengutronix.de, Frank.Li@freescale.com,
gregkh@linuxfoundation.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <530B9243.4020909@cogentembedded.com>
> On 02/24/2014 05:21 AM, Peter Chen wrote:
>
> > This API is used to set wakeup enable at PHY registers, in that case,
> > the PHY can be waken up from suspend due to external events, like vbus
> > change, dp/dm change and id change.
>
> > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > ---
> > include/linux/usb/phy.h | 16 ++++++++++++++++
> > 1 files changed, 16 insertions(+), 0 deletions(-)
>
> > diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h index
> > 6c0b1c5..c2c6f49 100644
> > --- a/include/linux/usb/phy.h
> > +++ b/include/linux/usb/phy.h
> > @@ -111,6 +111,13 @@ struct usb_phy {
> > int (*set_suspend)(struct usb_phy *x,
> > int suspend);
> >
> > + /*
> > + * Set wakeup enable for PHY, in that case, the PHY can be
> > + * waken up from suspend status due to external events,
>
> s/waken/woken/
>
> WBR, Sergei
>
>
Thanks, will change.
Peter
^ permalink raw reply
* Re: [PATCH] ARM: tegra: add device tree for SHIELD
From: Alexandre Courbot @ 2014-02-25 2:13 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King
Cc: linux-tegra@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <530B952D.2000006@wwwdotorg.org>
On 02/25/2014 03:53 AM, Stephen Warren wrote:
> On 02/24/2014 03:26 AM, Alexandre Courbot wrote:
>> Add a device tree for NVIDIA SHIELD. The set of enabled features is
>> still minimal with no display option (although HDMI should be easy
>> to get to work) and USB requiring external power.
>
> You could add a simple-framebuffer node for now, I think?
That would not be useful I'm afraid, since the DSI clocks will be
switched off in the absence of a dsi DT node in host1x, so you would end
up with a blank screen. Our best shot at display for the moment would be
HDMI, but I need to spend some more time on it.
Proper internal panel support would require a panel driver with the
proper DSI initialization sequences. It is in my pipe.
>> diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
>
>> + memory {
>> + reg = <0x80000000 0x79600000>;
>
> It might be worth a comment here pointing out that the rest of RAM is
> reserved for some carveouts/..., or at least that these values are set
> this way in order to match what the bootloader usually passes to
> downstream kernels in the command-line?
Yes, absolutely right. On a more general note I feel like DTs could gain
clarity if they had more comments (e.g. for pinmuxing which are a quite
heavy block otherwise), do you have any objection to this? (I guess not,
but so far the rule seems to be "no comment in DT" :P )
>
>> + i2c@7000d000 {
>
>> + palmas: pmic@58 {
>> + compatible = "ti,palmas";
>> + reg = <0x58>;
>> + interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
>> + ti,irq-externally-inverted;
>
> Unfortunately, the patch I sent to document/implement that last property
> hasn't yet been ack'd/applied, so I'll hold off applying this until it has.
That's fine, I wanted to avoid sending another patch soon after just for
that particular change.
>
>> + /* Wifi */
>> + sdhci@78000000 {
>> + status = "okay";
>> + bus-width = <4>;
>> + broken-cd;
>> + keep-power-in-suspend;
>> + cap-sdio-irq;
>
> Is non-removable better than broken-cd, or are they entirely unrelated?
They are unrelated actually. With non-removable the driver expects the
device to always be there since boot, and does not check for the card to
be removed/added after boot. broken-cd indicates there is no CD line and
the device should be polled regularly.
For the Wifi chip, non-removable would be the correct setting
hardware-wise, but there is a trap: the chip has its reset line asserted
at boot-time, and you need to set GPIO 229 to de-assert it. Only after
that will the device be detected on the SDIO bus. Since it lacks a CD
line, it must be polled, hence the broken-cd property.
This also raises another, redundant problem with DT bindings: AFAIK we
currently have no way to let the system know the device will only appear
after a given GPIO is set. It would also be nice to be able to give some
parameters to the Wifi driver through the DT (like the OOB interrupt).
Right now the Wifi chip is brought up by exporting the GPIO and writing
to it from user-space, and the OOB interrupt is not used.
Otherwise, Wifi works great with the brcmfmac driver and NVRAM file
extracted from Android.
> Should we add broken-cd and/or cap-sdio-irq to the SDIO WiFi on other
> boards (Springbank, Ventana, Cardhu)?
If they don't have the GPIO requirement that SHIELD has, I don't think
it is necessary. non-removable is probably a better property for
soldered Wifi chips.
I'm not sure about cap-sdio-irq, it doesn't seem to make a difference
for SHIELD Wifi.
>
>> + usb-phy@7d000000 {
>> + status = "okay";
>> + nvidia,xcvr-setup = <7>;
>> + nvidia,xcvr-lsfslew = <2>;
>> + nvidia,xcvr-lsrslew = <2>;
>> + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
>> + dr_mode = "otg";
>
> While opt is probably accurate, we don't actually support otg upstream,
> but only host. While the DT is supposed to represent HW rather than
> SW/OS details, I've tried to avoid putting otg into the DT, since I'm
> not sure that the DT binding for otg is stable, since we can't test it,
> whereas host probably is. Still, this is a pretty minor detail, and we
> can ignore that if you want ("otg" evidently /works/ fine on Seaboard,
> so it's OK if you keep this).
The setting works for me and the binding is documented, so maybe we can
keep it as-is?
Thanks for the review - v2 will be on the way, as well as Tegra Note 7
hopefully.
Alex.
^ permalink raw reply
* Re: [PATCH v5 4/8] Documentation: add the document for the SPI NOR framework
From: Huang Shijie @ 2014-02-25 2:23 UTC (permalink / raw)
To: Konstantin Tokarev
Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
angus.clark-qxv4g6HH51o@public.gmane.org,
shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
b44548-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
b18965-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
pekon-l0cyMroinI0@public.gmane.org,
sourav.poddar-l0cyMroinI0@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <203101393255036-NPKjhoV82L1xpj1cXAZ9Bg@public.gmane.org>
于 2014年02月24日 23:17, Konstantin Tokarev 写道:
> should know
sorry for my poor english. thanks a lot.
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-25 2:32 UTC (permalink / raw)
To: Austin, Brian
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, pawel.moll@arm.com,
ijc+devicetree@hellion.org.uk, Mark Brown,
linux-doc@vger.kernel.org, Liam Girdwood, Handrigan, Paul,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, rob@landley.net,
galak@codeaurora.org, grant.likely@linaro.org
In-Reply-To: <FF523989-CEF7-4A91-92A0-63D5FB90D897@cirrus.com>
On Mon, Feb 24, 2014 at 04:32:06PM +0000, Austin, Brian wrote:
>
> On Feb 24, 2014, at 10:06 AM, Nicolin Chen <Guangyu.Chen@freescale.com> wrote:
>
> > On Mon, Feb 24, 2014 at 03:52:24PM +0000, Austin, Brian wrote:
> >>>> + if (!IS_ERR(cs42888->clk))
> >>>> + clk_disable_unprepare(cs42888->clk);
> >>>
> >>> Does the device work without MCLK?
> >> Yes, MCLK is required. If you can’t get the clock you should error out.
> >
> > Wait...Regarding this clock part, I just forgot the reason I put the code:
> >
> > 385 cs42888->clk = devm_clk_get(&i2c->dev, "mclk");
> > 386 if (IS_ERR(cs42888->clk))
> > 387 dev_warn(&i2c->dev, "failed to get the clock: %ld\n",
> > 388 PTR_ERR(cs42888->clk));
> >
> > was because the MCLK might be provided from SoC (DAI master) so it could
> > be totally controlled by CPU DAI driver, ESAI for example has its own
> > dividers to derive the HCKT clock (MCLK for Tx) from ahb clock in SoC
> > clock tree, in which case we might not easily pass a valid clock phandle
> > via DT. (RFC to this thought.)
> OK, It’s an external MCLK source, so why not just handle that in the machine driver?
> Usually you would want the clock enabled/disabled in the machine driver so if you don’t get it, you can bail out there.
> At least that is how I do our MCLK’s. Since you are only using the freq of the clock to derive modes, just put the clock initialization outside and just pass in the freq like you do in set_sysclk
Letting codec handle the clock here is trying to en/disable it only when using
it -- pm_runtime_resume/suspend() so that we can save power during idle states,
while putting it into machine driver, quite common in lots of machine drivers
though, would need us to enable it in the probe(), otherwise machine driver
can't finish the clock enabling before codec driver's pm_runtime_resume() as
pm_runtime_get_sync(codec_dai->dev) is almost the head of soc_pcm_open().
At first place, I did let this codec driver be totally exempt from this clock
handling. And it's quite fair and neat to do that in the machine driver till
this second thought came to me....
Thank you,
Nicolin Chen
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-25 2:38 UTC (permalink / raw)
To: Mark Brown
Cc: Austin, Brian, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <20140225000027.GI25940@sirena.org.uk>
On Tue, Feb 25, 2014 at 09:00:27AM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 12:06:49AM +0800, Nicolin Chen wrote:
> > On Mon, Feb 24, 2014 at 03:52:24PM +0000, Austin, Brian wrote:
>
> > Wait...Regarding this clock part, I just forgot the reason I put the code:
>
> > 385 cs42888->clk = devm_clk_get(&i2c->dev, "mclk");
> > 386 if (IS_ERR(cs42888->clk))
> > 387 dev_warn(&i2c->dev, "failed to get the clock: %ld\n",
> > 388 PTR_ERR(cs42888->clk));
>
> > was because the MCLK might be provided from SoC (DAI master) so it could
> > be totally controlled by CPU DAI driver, ESAI for example has its own
> > dividers to derive the HCKT clock (MCLK for Tx) from ahb clock in SoC
> > clock tree, in which case we might not easily pass a valid clock phandle
> > via DT. (RFC to this thought.)
>
> We should be getting those clocks visible in the clock API rather than
> doing this.
Hmm...my words might not be so clear last time: we have to handle the dividers
of ESAI in ESAI driver because the dividers is in the ESAI's IP, not in the SoC
clock controlling unit. So it's hard to get them visible in the clock tree.
Thank you,
Nicolin
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-25 2:39 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: broonie, brian.austin, Paul.Handrigan, mark.rutland, devicetree,
alsa-devel, pawel.moll, ijc+devicetree, linux-doc, lgirdwood,
linux-kernel, robh+dt, rob, galak, grant.likely
In-Reply-To: <530B8741.3010302@metafoo.de>
On Mon, Feb 24, 2014 at 06:54:09PM +0100, Lars-Peter Clausen wrote:
> Hi,
>
> Couple of trivial things.
Will fix them all.
Thanks a lot,
Nicolin Chen
>
> On 02/24/2014 07:55 AM, Nicolin Chen wrote:
> [...]
> >+config SND_SOC_CS42888
> >+ tristate "Cirrus Logic CS42888 CODEC"
> >+ depends on I2C
>
> should select REGMAP_I2C
>
> >+
> [...]
> >+#define CS42888_NUM_SUPPLIES 4
> >+static const char *cs42888_supply_names[CS42888_NUM_SUPPLIES] = {
>
> const char *const
>
> >+ "VA",
> >+ "VD",
> >+ "VLS",
> >+ "VLC",
> >+};
> >+
> >+static const char *cs42888_adc_single[] = { "Differential", "Single-Ended" };
>
> const char * const
>
> >+static const char *cs42888_szc[] = { "Immediate Change", "Zero Cross",
> >+ "Soft Ramp", "Soft Ramp on Zero Cross" };
> >+
>
> const char * constr
>
> >+static const struct soc_enum cs42888_enum[] = {
> >+ SOC_ENUM_SINGLE(CS42888_ADCCTL, 4, 2, cs42888_adc_single),
> >+ SOC_ENUM_SINGLE(CS42888_ADCCTL, 3, 2, cs42888_adc_single),
> >+ SOC_ENUM_SINGLE(CS42888_TXCTL, 5, 4, cs42888_szc),
> >+ SOC_ENUM_SINGLE(CS42888_TXCTL, 0, 4, cs42888_szc),
> >+};
>
> Usually it makes things a bit more clearer when you have a variable
> with a unique name for each enum rather then putting them into one
> large array.
>
> >+
> [...]
> >+static struct cs42888_ratios cs42888_ratios[] = {
>
> const
>
> [...]
> >+static struct snd_soc_dai_ops cs42888_dai_ops = {
>
> const
>
> >+ .set_fmt = cs42888_set_dai_fmt,
> >+ .set_sysclk = cs42888_set_dai_sysclk,
> >+ .hw_params = cs42888_hw_params,
> >+ .digital_mute = cs42888_digital_mute,
> >+};
> >+
> [...]
> >+
> >+static struct reg_default cs42888_reg[] = {
>
> const
> [...]
> >+
> >+static struct snd_soc_codec_driver cs42888_driver = {
>
> const
>
> >+ .probe = cs42888_probe,
> >+ .idle_bias_off = true,
> >+
> >+ .controls = cs42888_snd_controls,
> >+ .num_controls = ARRAY_SIZE(cs42888_snd_controls),
> >+ .dapm_widgets = cs42888_dapm_widgets,
> >+ .num_dapm_widgets = ARRAY_SIZE(cs42888_dapm_widgets),
> >+ .dapm_routes = cs42888_dapm_routes,
> >+ .num_dapm_routes = ARRAY_SIZE(cs42888_dapm_routes),
> >+};
> >+
>
>
>
^ permalink raw reply
* Re: [PATCH V2] ARM: bcm2835: fix clock DT node names
From: Stephen Warren @ 2014-02-25 2:48 UTC (permalink / raw)
Cc: Emilio López, Mark Rutland, Mike Turquette,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1392960587-29355-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 02/20/2014 10:29 PM, Stephen Warren wrote:
> DT nodes should be named according to the type of object that they
> represent rather than the identity. DT nodes that contain a reg
> property should include a unit address in their name. Fix these issues.
>
> Add clock-output-names properties to the nodes so that the clocks get
> named something meaningful. This works around the fact that the fixed
> clock driver names clocks after the short node name, i.e. not including
> the unit address.
I've applied this to bcm2835's for-3.15/dt branch.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] ARM: Exynos: Add generic compatible string
From: Sachin Kamat @ 2014-02-25 3:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Kukjin Kim, Tomasz Figa, Arnd Bergmann, linux-arm-kernel,
Mark Rutland, devicetree@vger.kernel.org, Ian Campbell,
Rob Herring, Grant Likely, linux-samsung-soc, Olof Johansson
In-Reply-To: <530BE93F.2070904@gmail.com>
On 25 February 2014 06:22, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 25.02.2014 01:35, Kukjin Kim wrote:
>>
>> On 02/24/14 21:03, Sachin Kamat wrote:
>>>
>>> On 21 February 2014 21:01, Tomasz Figa<t.figa@samsung.com> wrote:
>>>>
>>>> On 21.02.2014 16:21, Tomasz Figa wrote:
>>>>>
>>>>>
>>>>> On 21.02.2014 15:48, Arnd Bergmann wrote:
>>>>>>
>>>>>>
>>>>>> On Friday 21 February 2014 14:18:49 Tomasz Figa wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Now that we have a broader agreement on this, I think we can go
>>>>>>>> ahead with the
>>>>>>>> following steps as an initial approach:
>>>>>>>> 1. Have a common machine file for both exynos4 and 5 files,
>>>>>>>> mach-exynos-dt.c.
>>>>>>>> 2. Introduce a generic compatible string "samsung,exynos".
>>
>>
>> Well, I think, we need to consider to use compatible string
>> "samsung,exynos" again because "exynos" name can be used on ARMv8 as
>> well and I don't want to say that generic/common something is always
>> good. So IMHO still using exynos4 and exynos5 would be better.
>
>
> You can create a new compatible string (e.g. "samsung,exynos-armv8") for
> ARMv8 Exynos if support for one in mainline shows up and/or simply use
> another name for ARMv7 Exynos (e.g. "samsung,exynos-armv7").
I think "samsung,exynos-armv7" would be better in case we need to
distinguish between
v7 and v8.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [Patch v7 2/2] dmaengine: add Qualcomm BAM dma driver
From: Mark Brown @ 2014-02-25 3:05 UTC (permalink / raw)
To: Felipe Balbi
Cc: Andy Gross, devicetree, Vinod Koul, linux-arm-msm, linux-kernel,
dmaengine, Dan Williams, linux-arm-kernel
In-Reply-To: <20140225000913.GA10801@saruman.home>
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
On Mon, Feb 24, 2014 at 06:09:13PM -0600, Felipe Balbi wrote:
> > + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
> do you really want to make it depend on ARM even when COMPILE_TEST=y ?
writel_relaxed() is unfortunately not generally available so it'd fail
to build on platforms like x86.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Mark Brown @ 2014-02-25 3:09 UTC (permalink / raw)
To: Nicolin Chen
Cc: Austin, Brian, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <20140225023840.GB7229@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Tue, Feb 25, 2014 at 10:38:41AM +0800, Nicolin Chen wrote:
> Hmm...my words might not be so clear last time: we have to handle the dividers
> of ESAI in ESAI driver because the dividers is in the ESAI's IP, not in the SoC
> clock controlling unit. So it's hard to get them visible in the clock tree.
We should be able to arrange to have the ESAI be a clock provider
shouldn't we? If the clocks need to interface to other things (and they
do) then we should be able to use the standard interface we have to
clocks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-25 3:13 UTC (permalink / raw)
To: Mark Brown
Cc: Austin, Brian, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <20140225030947.GO25940@sirena.org.uk>
On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 10:38:41AM +0800, Nicolin Chen wrote:
>
> > Hmm...my words might not be so clear last time: we have to handle the dividers
> > of ESAI in ESAI driver because the dividers is in the ESAI's IP, not in the SoC
> > clock controlling unit. So it's hard to get them visible in the clock tree.
>
> We should be able to arrange to have the ESAI be a clock provider
> shouldn't we? If the clocks need to interface to other things (and they
> do) then we should be able to use the standard interface we have to
> clocks.
Excuse me, I think I just don't get the approach how to use clock API to
standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
so we couldn't register in DT and it's not SoC internal clock which means
we couldn't register it in the SoC clock driver either.
Could you please shed me some light on it?
Thank you,
Nicolin Chen
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Mark Brown @ 2014-02-25 3:39 UTC (permalink / raw)
To: Nicolin Chen
Cc: Austin, Brian, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <20140225031313.GA7343@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
On Tue, Feb 25, 2014 at 11:13:14AM +0800, Nicolin Chen wrote:
> On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:
> > We should be able to arrange to have the ESAI be a clock provider
> > shouldn't we? If the clocks need to interface to other things (and they
> > do) then we should be able to use the standard interface we have to
> > clocks.
> Excuse me, I think I just don't get the approach how to use clock API to
> standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
> so we couldn't register in DT and it's not SoC internal clock which means
> we couldn't register it in the SoC clock driver either.
> Could you please shed me some light on it?
So register it from the ESAI driver then.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-25 3:46 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Austin, Brian,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk,
linux-doc@vger.kernel.org, Liam Girdwood, Handrigan, Paul,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, rob@landley.net,
galak@codeaurora.org, grant.likely@linaro.org,
alsa-devel@alsa-project.org
In-Reply-To: <20140225033929.GP25940@sirena.org.uk>
On Tue, Feb 25, 2014 at 12:39:29PM +0900, Mark Brown wrote:
> On Tue, Feb 25, 2014 at 11:13:14AM +0800, Nicolin Chen wrote:
> > On Tue, Feb 25, 2014 at 12:09:47PM +0900, Mark Brown wrote:
>
> > > We should be able to arrange to have the ESAI be a clock provider
> > > shouldn't we? If the clocks need to interface to other things (and they
> > > do) then we should be able to use the standard interface we have to
> > > clocks.
>
> > Excuse me, I think I just don't get the approach how to use clock API to
> > standardize the MCLK derived from ESAI IP: it's surely not a fixed-clock
> > so we couldn't register in DT and it's not SoC internal clock which means
> > we couldn't register it in the SoC clock driver either.
>
> > Could you please shed me some light on it?
>
> So register it from the ESAI driver then.
Then I think I need to find a way to pass the clock to CODEC driver...
Anyway, I'll try it first. Thank you.
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Mark Brown @ 2014-02-25 3:52 UTC (permalink / raw)
To: Nicolin Chen
Cc: Austin, Brian, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <20140225034635.GB7343@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Tue, Feb 25, 2014 at 11:46:36AM +0800, Nicolin Chen wrote:
> On Tue, Feb 25, 2014 at 12:39:29PM +0900, Mark Brown wrote:
> > So register it from the ESAI driver then.
> Then I think I need to find a way to pass the clock to CODEC driver...
Won't the normal DT mechanisms work here? I'd expect them to, you can
already have multiple clock providers in a system.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC: cs42888: Add codec driver support
From: Fabio Estevam @ 2014-02-25 3:54 UTC (permalink / raw)
To: Nicolin Chen
Cc: Mark Brown, mark.rutland@arm.com, devicetree@vger.kernel.org,
Austin, Brian, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk,
linux-doc@vger.kernel.org, Liam Girdwood, Handrigan, Paul,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, rob@landley.net,
galak@codeaurora.org, grant.likely@linaro.org,
alsa-devel@alsa-project.org
In-Reply-To: <20140225034635.GB7343@MrMyself>
Hi Nicolin,
On Tue, Feb 25, 2014 at 12:46 AM, Nicolin Chen
<Guangyu.Chen@freescale.com> wrote:
>> So register it from the ESAI driver then.
>
> Then I think I need to find a way to pass the clock to CODEC driver...
Does this example from mxs-saif help?
commit 7c9e6150f2e7cbd60e0bc9a19118ca1dc97d2780
Author: Shawn Guo <shawn.guo@linaro.org>
Date: Mon Jul 1 16:16:10 2013 +0800
ASoC: mxs: register saif mclk to clock framework
Mostly the mxs system design uses saif0 mclk output as the clock source
of codec. Since the mclk is implemented as a general divider with the
saif clk as the parent clock, let's register the mclk as a basic
clk-divider to common clock framework. Then with it being a clock
provdier, clk_get() call in codec driver probe function will just work.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
^ 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