On 5/31/19 7:06 AM, Radu Nicolae Pirea wrote:
> Caution: EXT Email
>
> Hi,
>
> @York I want to continue the work on this driver and I want to upstream
> it. Are you OK with this?
>
> I saw later improvement suggestions related to the bindings and I will
> make the changes.
Radu,
You are welcom
On 12/5/18 2:54 PM, Tracy Smith wrote:
>>> Question 4) If so, will a panic ever be called if there is a hardware
>>> uncorrectable memory failure?
>
>> No. It is up to upper layer of EDAC driver. Layerscape driver only reports
>> CEs and UEs.
>
> Just to be clear, the upper layer of the EDAC dri
On 12/5/18 2:00 PM, Tracy Smith wrote:
>> Single-bit errors are corrected by memory controller without involving
>> software.
>
> Sorry for being verbose, but I need to explain the reason for the
> questions below since I need to determine if a memory scrub is
> required on layerscape and why. T
On 12/5/18 8:38 AM, Tracy Smith wrote:
> This is more directed toward York for layerscape. I see some edac code
> that seem to do periodic scrubs based on intervals or scrub rate, but
> that is not needed for the layerscape driver to correct errors because
> errors are scrubbed when found by the ed
C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636567177956904165&sdata=xWmuUtS9dk7PSq1R11L%2F4vpoztnXATAPgtmiqytpnAs%3D&reserved=0
> )
>
> Some comments below, I haven't looked in to edac or the manuals for A53/A57.
>
> On 15/03/18 00:17, York Sun wrote:
>> Add erro
On 03/15/2018 08:07 AM, Mark Rutland wrote:
> Hi York,
>
> On Wed, Mar 14, 2018 at 05:17:46PM -0700, York Sun wrote:
>> Add error detection for A53 and A57 cores. Hardware error injection
>> is supported on A53. Software error injection is supported on both.
>> For hard
On 03/15/2018 03:18 AM, Borislav Petkov wrote:
> On Thu, Mar 15, 2018 at 01:20:18AM +0000, York Sun wrote:
>> The discussion led to using device tree to specify which cores have this
>> feature. Since this feature is "implementation dependent", I can only
>> conf
On 03/14/2018 06:08 PM, Borislav Petkov wrote:
> On Wed, Mar 14, 2018 at 05:17:46PM -0700, York Sun wrote:
>> Add error detection for A53 and A57 cores. Hardware error injection
>> is supported on A53. Software error injection is supported on both.
>> For hardware error inj
Add edac node to enable error detection for L1 and L2 cache.
Signed-off-by: York Sun
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 9 +
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 9 +
2 files changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl
the driver. Failure to enable access
disables hardware error injection. For error interrupt to work,
another SMC call enables access to L2ECTLR_EL1. Failure to enable
access disables interrupt for error reporting.
Signed-off-by: York Sun
---
.../devicetree/bindings/edac/cortex-arm64-edac.txt
Then you are good to go.
York
Sent from my iPhone
> On Feb 22, 2018, at 22:40, Rasmus Villemoes
> wrote:
>
>> On 2018-02-20 22:01, York Sun wrote:
>> Sorry for top posting. I am on vacation and replying from my phone.
>>
>> The controller is compatible a
Sorry for top posting. I am on vacation and replying from my phone.
The controller is compatible and the driver should work. Please double check to
make sure you can inject errors and receive interrupt. After that you are good
to go.
York
Sent from my iPhone
> On Feb 20, 2018, at 23:09, Rasmu
On 09/14/2017 12:54 PM, York Sun wrote:
> On 07/27/2017 03:05 AM, yinbo@nxp.com wrote:
>> From: Rajesh Bhagat
>>
>> +#elif defined(CONFIG_LS102XA) || defined(CONFIG_ARCH_LS1012A)
>
> Please use CONFIG_ARCH_LS1021A, not CONFIG_LS102XA.
>
Never mind. This is
On 07/27/2017 03:05 AM, yinbo@nxp.com wrote:
> From: Rajesh Bhagat
>
> Add USB EHCI support for ls1012aqds platform
>
> Signed-off-by: Rajat Srivastava
> Signed-off-by: Rajesh Bhagat
> Signed-off-by: yinbo.zhu
> ---
> arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 1 +
> incl
On 11/15/2016 10:26 PM, yanjiang@windriver.com wrote:
> From: Yanjiang Jin
>
> Tested on a T4240QDS board.
>
> If we execute the below steps without this patch:
>
> 1. modprobe mpc85xx_edac [The first insmod, everything is well.]
> 2. modprobe -r mpc85xx_edac
> 3. modprobe mpc85xx_edac [insmod
On 09/02/2016 07:04 AM, Rob Herring wrote:
> On Fri, Aug 26, 2016 at 02:45:49PM -0700, York Sun wrote:
>> From: York Sun
>>
>> SI5338 is a programmable clock generator. It has 4 sets of inputs,
>> PLL, multisynth and dividers to make 4 outputs. This driver splits
>
On 08/30/2016 03:58 AM, Shawn Guo wrote:
> On Tue, Aug 09, 2016 at 02:59:39PM -0700, York Sun wrote:
>> Add DDR memory controller nodes to enable EDAC driver.
>>
>> Signed-off-by: York Sun
>
> The patch subject is too general. I changed it to "arm64: dts:
From: York Sun
SI5338 is a programmable clock generator. It has 4 sets of inputs,
PLL, multisynth and dividers to make 4 outputs. This driver splits
them into multiple clocks to comply with common clock framework.
See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
details
On 08/23/2016 09:48 PM, Stephen Boyd wrote:
> On 08/24, kbuild test robot wrote:
>>
>> 2827 if (drv_type < 0)
>> 2828 return drv_type;
>> 2829
>> 2830 drv_vdd = get_drv_vdd(drvdata, i);
>> 2831 if (drv_vdd < 0)
>> 2
Add DDR EDAC for ARM-based compatible controllers. Both big-endian
and little-endian are supported, as specified in device tree.
Signed-off-by: York Sun
---
Change log
v5: Update author and copyright for the new driver
Drop initializing varaible with 0
Add pr_fmt macro
v4: Drop
+Shawn Guo
On 08/09/2016 03:00 PM, York Sun wrote:
> Add DDR memory controller nodes to enable EDAC driver.
>
> Signed-off-by: York Sun
>
> ---
> Change log
> v4: no change
> v3: no change
> v2: no change
>
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dts
From: York Sun
SI5338 is a programmable clock generator. It has 4 sets of inputs,
PLL, multisynth and dividers to make 4 outputs. This driver splits
them into multiple clocks to comply with common clock framework.
See Documentation/devicetree/bindings/clock/silabs,si5338.txt for
details
Replace obsolete simple_strtoul() with kstrtoul().
Signed-off-by: York Sun
---
drivers/edac/fsl_ddr_edac.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index afade14..4ddf838 100644
On 08/12/2016 02:13 AM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 02:55:45PM -0700, York Sun wrote:
>> Add DDR EDAC for ARM-based compatible controllers. Both big-endian
>> and little-endian are supported, as specified in device tree.
>>
>> Signed-off-by: York S
On 08/11/2016 06:36 AM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 02:55:40PM -0700, York Sun wrote:
>> The mpc85xx compatible DDR controllers are used on ARM-based SoCs.
>> Separate the DDR part from mpc85xx EDAC driver and prepare to support
>> both architecture.
>
The mpc85xx compatible DDR controllers are used on ARM-based SoCs.
Separate the DDR part from mpc85xx EDAC driver and prepare to support
both architecture.
Signed-off-by: York Sun
---
Change log
v5: Rebase onto git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git
edac-for-4.9
On 08/11/2016 06:36 AM, Borislav Petkov wrote:
>
> Please regenerate it against:
>
> http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git#edac-for-4.9
>
Will do.
York
When compiled as a module, removing this module causes kernel
warnings when irq_dispose_mapping() is called. Instead of calling
irq_of_parse_and_map(), using platform_get_irq() to acquire the
IRQ number.
Signed-off-by: York Sun
---
Change log
v4: Absorb name changes by "Rename macro
Get endianness from device tree. Both big endian and little endian
are supported. Default to big endian for backward compatibility to
MPC85xx.
Signed-off-by: York Sun
---
Change log
v4: Absorb name changes by "Rename macros and names"
Drop testing for big-endian as suggested
Add DDR memory controller nodes to enable EDAC driver.
Signed-off-by: York Sun
---
Change log
v4: no change
v3: no change
v2: no change
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 7 +++
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 14 ++
2 files changed, 21
Add DDR EDAC for ARM-based compatible controllers. Both big-endian
and little-endian are supported, as specified in device tree.
Signed-off-by: York Sun
---
Change log
v4: Drop adding atomic_scrub() for arm64
Drop NO_IRQ
v3: no change
v2: Create new driver using shared DDR object
The mpc85xx compatible DDR controllers are used on ARM-based SoCs.
Separate the DDR part from mpc85xx EDAC driver and prepare to support
both architecture.
Signed-off-by: York Sun
---
Change log
v4: Change comment in file header
Use lower case "fsl_ddr_edac" for EDAC_MOD_STR
The compatible DDR controllers may support DDR, DDR2, DDR3, DDR4. An
individual controller doesn't support all of them. EDAC driver reads
the controller to determine which mode is running.
Signed-off-by: York Sun
---
Change log
v4: Drop DSC_SDTYPE_DDR* macros, use naked numbers as sugg
mc doesn't support this bit. It is more reasonable
to leave RFXE as is in EDAC driver, and leave the uncorrectable
errors triggering machine check for e500v1.
Signed-off-by: York Sun
Suggested-by: Scott Wood
---
Change log
v4: Fix typo in commit message
v3: Revise commit message
v2: ne
Use generic names for macros, variables and functions.
Signed-off-by: York Sun
---
Change log
v4: Replace MPC85XX_MC_* with FSL_MC_*
v3: Absort changes from reording patches
v2: Separated from "House cleaning" patch of v1
drivers/edac/fsl_ddr_ed
Replace printk with more preferred pr_err/pr_warn/pr_info format.
Signed-off-by: York Sun
---
Change log
v4: no change
v3: no change
v2: Reordered patch. Change more printk statement than v1 patch.
drivers/edac/mpc85xx_edac.c | 72 ++---
1 file
On 08/08/2016 11:56 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 05:06:39AM +0000, york sun wrote:
>> It is uncorrectable. DDR controller can only report the error. I don't
>> believe EDAC driver can do more. For the same reason I said we can leave
>> RXFE as is,
On 08/09/2016 08:57 AM, york@nxp.com wrote:
> On 08/08/2016 11:56 PM, Borislav Petkov wrote:
>> On Tue, Aug 09, 2016 at 05:06:39AM +0000, york sun wrote:
>>> It is uncorrectable. DDR controller can only report the error. I don't
>>> believe EDAC driver can do
On 08/09/2016 04:12 AM, Will Deacon wrote:
> On Mon, Aug 08, 2016 at 07:56:04PM +0000, york sun wrote:
>> On 08/08/2016 11:07 AM, Marc Zyngier wrote:
>>> On Thu, 4 Aug 2016 15:58:35 -0700
>>> York Sun wrote:
>>>
>>>> Add DDR EDAC for ARM-based
On 08/08/2016 10:01 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 04:31:19AM +0000, york sun wrote:
>> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
>> handled by EDAC.
>
> And how is mpc85_xxx EDAC handling them?
>
> mpc85xx_mc_check() only
On 08/08/2016 08:32 PM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:39:44PM +0000, york sun wrote:
>> RFXE is cleared by default. So for most SoCs, this is not even a concern
>> at all. But for e500v1, when RIO or PCI are used, this bit is set
>> specifically to catc
On 08/08/2016 01:50 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:33PM -0700, York Sun wrote:
>> Get endianness from device tree. Both big endian and little endian
>> are supported. Default to big endian for backward compatibility to
>> MPC85xx.
>>
On 08/08/2016 01:31 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:32PM -0700, York Sun wrote:
>
> <--- Missing commit message.
>
>> Signed-off-by: York Sun
>>
>> ---
>> Change log
>> v3: no change
>> v2: no change
>>
>
On 08/08/2016 11:07 AM, Marc Zyngier wrote:
> On Thu, 4 Aug 2016 15:58:35 -0700
> York Sun wrote:
>
>> Add DDR EDAC for ARM-based compatible controllers. Both big-endian
>> and little-endian are supported.
>>
>> Signed-off-by: York Sun
>>
>> ---
>
On 08/05/2016 12:01 AM, Borislav Petkov wrote:
> On Fri, Aug 05, 2016 at 04:26:26AM +0000, york sun wrote:
>> I don't have deep knowledge of this driver. What I am trying is to
>> separate the common DDR part and share it with ARM platforms. Along the
>> way, I found the
On 08/08/2016 12:37 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:30PM -0700, York Sun wrote:
>> The mpc85xx compatible DDR controllers are used on ARM-based SoCs.
>> Separate the DDR part from mpc85xx EDAC driver and prepare to support
>> both architecture.
>
On 08/08/2016 12:11 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:28PM -0700, York Sun wrote:
>> On e500v1, read fault exception enable (RFXE) controls whether
>> assertion of core_fault_in causes a machine check interrupt.
>> Assertion of core_fault_in can resu
On 08/08/2016 01:57 AM, Alexander Stein wrote:
> On Thursday 04 August 2016 15:58:35, York Sun wrote:
>> Add DDR EDAC for ARM-based compatible controllers. Both big-endian
>> and little-endian are supported.
>>
>> Signed-off-by: York Sun
>>
>> ---
>>
On 08/08/2016 12:41 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:31PM -0700, York Sun wrote:
>> Use generic names for macros, variables and functions.
>>
>> Signed-off-by: York Sun
>>
>> ---
>> Change log
>> v3: Absort changes from pre
On 08/04/2016 08:43 PM, Michael Ellerman wrote:
> York Sun writes:
>
>> Two symbols are missing if mpc85xx_edac driver is compiled as module.
>>
>> Signed-off-by: York Sun
>>
>> ---
>> Change log
>> v3: Change subject tag
>> v2: no chang
On 08/05/2016 02:09 PM, Scott Wood wrote:
> On Fri, 2016-08-05 at 20:29 +0000, york sun wrote:
>> On 08/04/2016 08:43 PM, Michael Ellerman wrote:
>>>
>>> Does the driver really need to use these routines? They're meant for use
>>> early in boot, before PC
On 08/04/2016 08:43 PM, Michael Ellerman wrote:
> York Sun writes:
>
>> Two symbols are missing if mpc85xx_edac driver is compiled as module.
>>
>> Signed-off-by: York Sun
>>
>> ---
>> Change log
>> v3: Change subject tag
>> v2: no chang
On 08/04/2016 04:36 PM, Andrew Donnellan wrote:
> On 05/08/16 08:58, York Sun wrote:
>> Two symbols are missing if mpc85xx_edac driver is compiled as module.
>>
>> Signed-off-by: York Sun
>
> Good catch! One comment below.
>
> Reviewed-by: Andrew Donnellan
>
&
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change
drivers/edac/fsl_ddr_edac.c | 12 ++--
drivers/edac/fsl_ddr_edac.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index 60761c0
Get endianness from device tree. Both big endian and little endian
are supported. Default to big endian for backward compatibility to
MPC85xx.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Separated from "Add support for ARM-based SoCs" patch
.../f
Add DDR EDAC for ARM-based compatible controllers. Both big-endian
and little-endian are supported.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Create new driver using shared DDR object
arch/arm64/Kconfig.platforms | 1 +
arch/{arm => arm64}/include/asm/edac.h |
Replace printk with more preferred pr_err/pr_warn/pr_info format.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Reordered patch. Change more printk statement than v1 patch.
drivers/edac/mpc85xx_edac.c | 72 ++---
1 file changed, 35
When compiled as a module, removing this module causes kernel
warnings when irq_dispose_mapping() is called. Instead of calling
irq_of_parse_and_map(), using platform_get_irq() to acquire the
IRQ number.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change
drivers/edac
Two symbols are missing if mpc85xx_edac driver is compiled as module.
Signed-off-by: York Sun
---
Change log
v3: Change subject tag
v2: no change
arch/powerpc/kernel/pci-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel
mc doesn't support this bit. It is more reasonable
to leave RFXE as is in EDAC driver, and leave the uncorrectable
errors triggering machine check for e500v1.
Signed-off-by: York Sun
Suggested-by: Scott Wood
---
Change log
v3: Revise commit message
v2: new patch in this set
Add DDR memory controller nodes to enable EDAC driver.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 7 +++
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 14 ++
2 files changed, 21 insertions
The mpc85xx compatible DDR controllers are used on ARM-based SoCs.
Separate the DDR part from mpc85xx EDAC driver and prepare to support
both architecture.
Signed-off-by: York Sun
---
Change log
v3: Fix compiling errors and warnings caused by patch ordering
v2: Reordered patch
Use generic names for macros, variables and functions.
Signed-off-by: York Sun
---
Change log
v3: Absort changes from previous patch after reording
v2: Separated from "House cleaning" patch of v1
drivers/edac/fsl_ddr_edac.c | 153 ++--
dr
This function is a copy from powerpc, and is never used on microblaze.
Signed-off-by: York Sun
Suggested-by: Bjorn Helgaas
---
This patch has nothing to do with this EDAC patch set, but suggested by
Bjorn Helgaas as good code hygiene, along with patch 01/11 to expose
early_find_capability
.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Paul Bolle
CC: Peter Korsgaard
CC: Alexander Sverdlin
---
Change log:
v5: Remove variable initial_state
Remove .owner = THIS_MODULE
v4: Rename no-read to write-only
Revise binding document
Revise endianness checking
Reorder
On 08/15/2015 01:23 PM, Wolfram Sang wrote:
> On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote:
>> Based on i2c-mux-gpio driver, similarly the register based mux
>> switch from one bus to another by setting a single register.
>> The register can be on PCIe bus, loc
.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Paul Bolle
CC: Peter Korsgaard
CC: Alexander Sverdlin
---
Change log:
v4: Rename no-read to write-only
Revise binding document
Revise endianness checking
Reorder in Kconfig and Makefile
Remove print for deferred probing
On 08/11/2015 06:35 PM, Wolfram Sang wrote:
>
>> Do I have to add myself to MAINTAINER file for this driver?
>
> Do you want to maintain this driver?
>
I prefer not, if that is OK.
York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
On 08/11/2015 01:02 PM, Wolfram Sang wrote:
>>> I'd think that "little-endian" or "big-endian" force a setting. If none
>>> is present, we shall take the CPU endianess. Or am I overlooking
>>> something?
>>
>> You are right. The current code checks for littel-endian property. If
>> missing,
>> t
On 08/11/2015 09:16 AM, Wolfram Sang wrote:
+ if (of_find_property(np, "little-endian", NULL)) {
>>>
>>> You should check for a "big-endian" property as well, no?
>>
>> I use the little-endian as an option to indicate the nature of litten-endian
>> register. It is default to big-endian if t
On 08/11/2015 08:39 AM, Wolfram Sang wrote:
> On Thu, Jun 18, 2015 at 12:57:38PM -0700, York Sun wrote:
>> Based on i2c-mux-gpio driver, similarly the register-based mux
>> switch from one bus to another by setting a single register.
>> The register can be on PCIe bus, loc
Dear Maintainers,
Please review and advise if any change is needed.
Thanks.
York
On 06/17/2015 11:49 AM, York Sun wrote:
> SI5338 is a programmable clock generator. It has 4 sets of inputs,
> PLL, multisynth and dividers to make 4 outputs. This driver splits
> them into multiple
.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Paul Bolle
CC: Peter Korsgaard
CC: Alexander Sverdlin
---
According to Alexander's feedback, readback is added. Different sizes
are supported. I stick with iowrite but adding an option to use iowrite
big endian in in case needed. Both big- and l
Paul,
Your review comments are very appreciated.
On 06/18/2015 02:18 AM, Paul Bolle wrote:
> York,
>
> On Wed, 2015-06-17 at 14:20 -0700, York Sun wrote:
>> Drop linux-i2c mailing list.
>
> (Looking at MAINTAINERS suggests that, besides Michael, Stephen Boyd and
> th
On 06/18/2015 05:35 AM, Alexander Sverdlin wrote:
> Hello!
>
> On 17/06/15 23:13, ext York Sun wrote:
>> +switch (mux->data.reg_size) {
>> +case 4:
>> +iowrite32(mux->data.values[chan], mux->data.reg);
>> +break;
>
York
On 06/17/2015 12:01 PM, York Sun wrote:
> COMMON_CLK has been a bool value, selected by the platforms who need
> common clock framework. If a CCF driver is needed on an add-on device
> such as PCIe card, COMMON_CLK can be selected individually as a
> tristate value.
>
> Signed
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
address.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Paul Bolle
CC: Peter Korsgaard
CC: Alexander
On 06/17/2015 12:05 PM, Wolfram Sang wrote:
> On Wed, Jun 17, 2015 at 12:01:47PM -0700, York Sun wrote:
>> COMMON_CLK has been a bool value, selected by the platforms who need
>> common clock framework. If a CCF driver is needed on an add-on device
>> such as PCIe ca
__clk_is_prepared from clk.c so drivers can check and unprepare
clocks upon removal.
Signed-off-by: York Sun
CC: Mike Turquette
CC: Sebastian Hesselbarth
CC: Guenter Roeck
CC: Andrey Filippov
CC: Paul Bolle
---
Change log:
v4: Add binding silabs,pll-vco
Set pll rate initial value
Separate
COMMON_CLK has been a bool value, selected by the platforms who need
common clock framework. If a CCF driver is needed on an add-on device
such as PCIe card, COMMON_CLK can be selected individually as a
tristate value.
Signed-off-by: York Sun
CC: Paul Bolle
CC: Mike Turquette
---
drivers/clk
On 06/17/2015 02:29 AM, Paul Bolle wrote:
> On Tue, 2015-06-16 at 09:31 -0700, York Sun wrote:
>> COMMON_CLK in Kconfig is changed from bool to tristate so all common
>> clock framework drivers can be selected by users.
>
> A bool to tristate change isn't needed to
On 06/17/2015 08:03 AM, Alexander Sverdlin wrote:
> Hi!
>
> On 16/06/15 19:28, ext York Sun wrote:
>> Based on i2c-mux-gpio driver, similarly the register based mux
>> switch from one bus to another by setting a single register.
>> The register can be on PCIe bu
Based on i2c-mux-gpio driver, similarly the register based mux
switch from one bus to another by setting a single register.
The register can be on PCIe bus, local bus, or any memory-mapped
address.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Peter Korsgaard
---
.../devicetree/bindings/i2c
is changed from bool to tristate so all common
clock framework drivers can be selected by users.
Export __clk_is_prepared from clk.c so drivers can check and unprepare
clocks upon removal.
Signed-off-by: York Sun
CC: Mike Turquette
CC: Sebastian Hesselbarth
CC: Guenter Roeck
CC: Andrey
On 06/16/2015 08:18 AM, York Sun wrote:
> Paul,
>
> Thanks for reviewing.
>
> On 06/16/2015 01:21 AM, Paul Bolle wrote:
>> One question and a few nits follow.
>>
>> On Mon, 2015-06-15 at 10:07 -0700, York Sun wrote:
>>> SI5338 is a programmable clock g
Paul,
Thanks for reviewing.
On 06/16/2015 01:21 AM, Paul Bolle wrote:
> One question and a few nits follow.
>
> On Mon, 2015-06-15 at 10:07 -0700, York Sun wrote:
>> SI5338 is a programmable clock generator. It has 4 sets of inputs,
>> PLL, multisynth and dividers to make 4
CLK_TWL6040) += clk-twl6040.o
diff --git a/drivers/clk/clk-si5338.c b/drivers/clk/clk-si5338.c
new file mode 100644
index 000..fa50050
--- /dev/null
+++ b/drivers/clk/clk-si5338.c
@@ -0,0 +1,3656 @@
+/*
+ * clk-si5338.c: Silicon Labs Si5338 I2C Clock Generator
+ *
+ * Copyright 2015 Fre
lk-s2mps11.o
+obj-$(CONFIG_COMMON_CLK_SI5338)+= clk-si5338.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
diff --git a/drivers/clk/clk-si5338.c b/driv
Michael,
I have rewritten the driver to use CCF. It will be sent for review when ready.
I have some questions, hoping you can shed some light on them.
Q1: What does of_clk_add_provider do?
I read the code and comment. It registers a clock provider for a node. How is it
used after registration?
Michael,
Let me start a new thread for more questions regarding common clock framework.
Following yours and other experts' suggestion, I start to write a new driver for
SI5338. As I explained earlier, I have multiple clock chips. They may have
different clock sources. I haven't figured out how to
On 05/27/2015 11:11 PM, Michael Turquette wrote:
>
> Hi Andrey,
>
> I think this is a cool problem to solve. As far as frontier devices go I
> really can't say. Other companies create similar clock generators that
> are programmed at run-time over i2c. And we already have support merged
> fo
On 05/27/2015 11:54 AM, Guenter Roeck wrote:
> On Wed, May 27, 2015 at 11:24:50AM -0700, York Sun wrote:
>>
>>>
>>> Someone suggested earlier that the clocks should be set from the PCIe
>>> driver.
>>> Question here is really if you need to control t
On 05/27/2015 11:15 AM, Guenter Roeck wrote:
> On Wed, May 27, 2015 at 10:45:32AM -0700, York Sun wrote:
>>
>>
>> On 05/27/2015 10:30 AM, Michael Turquette wrote:
>>> Quoting York Sun (2015-05-26 17:32:13)
>>>> Michael,
>>>>
>>>>
On 05/27/2015 10:30 AM, Michael Turquette wrote:
> Quoting York Sun (2015-05-26 17:32:13)
>> Michael,
>>
>> Can you give me some guidance here?
>>
>>
>> On 05/26/2015 05:20 PM, York Sun wrote:
>>>
>>>
>>> On 05/26/2015 03:38 PM,
On 05/27/2015 10:09 AM, Guenter Roeck wrote:
> On Wed, May 27, 2015 at 09:46:02AM -0700, York Sun wrote:
>>
> [ ... ]
>>
>> Sebastian,
>>
>> Thanks for the insight. Looks like I should give up upstreaming this driver.
>> I
>> will find other ways
On 05/27/2015 09:42 AM, Sebastian Hesselbarth wrote:
> On 27.05.2015 17:07, York Sun wrote:
>> On 05/27/2015 12:09 AM, Sebastian Hesselbarth wrote:
> [...]
>>> Also, why should a user ever be able to mess with the clocks? If you
>>> allow a user to change the cloc
On 05/27/2015 12:09 AM, Sebastian Hesselbarth wrote:
> On 27.05.2015 02:32, York Sun wrote:
>> On 05/26/2015 05:20 PM, York Sun wrote:
>>> On 05/26/2015 03:38 PM, Guenter Roeck wrote:
>>>> On Tue, May 26, 2015 at 12:12:11PM -0700, York Sun wrote:
>>>>&g
Michael,
Can you give me some guidance here?
On 05/26/2015 05:20 PM, York Sun wrote:
>
>
> On 05/26/2015 03:38 PM, Guenter Roeck wrote:
>> On Tue, May 26, 2015 at 12:12:11PM -0700, York Sun wrote:
>>> Linux experts,
>>>
>>> I have rewritten a driver
On 05/26/2015 03:38 PM, Guenter Roeck wrote:
> On Tue, May 26, 2015 at 12:12:11PM -0700, York Sun wrote:
>> Linux experts,
>>
>> I have rewritten a driver for Silicon Labs SI5338 programmable clock chip.
>> The
>> original driver was written by Andrey (CC&
Linux experts,
I have rewritten a driver for Silicon Labs SI5338 programmable clock chip. The
original driver was written by Andrey (CC'ed), but was floatingn outside of the
kernel. The driver was written to use sysfs as the interface, not the common
clock framework. I wonder if I have to rewrite
1 - 100 of 107 matches
Mail list logo
