I am not sure if this mail will reach the list as I am not subscribed.
In the v2 patch (actually both version), you wrote
> + byte = readb(i2c->base + MPC_I2C_DR);
> +
> + /* Adjust length if first received byte is length */
> + if (i == 0 && recv_len) {
> +
On Wed, 2011-11-16 at 09:36 -0800, Guenter Roeck wrote:
> On Wed, 2011-11-16 at 12:28 -0500, York Sun wrote:
> > I am not sure if this mail will reach the list as I am not subscribed.
> >
> > In the v2 patch (actually both version), you wrote
> >
> > &
On Wed, 2011-11-16 at 19:09 +0100, Jean Delvare wrote:
> On Wed, 16 Nov 2011 09:55:35 -0800, York Sun wrote:
> > On Wed, 2011-11-16 at 09:36 -0800, Guenter Roeck wrote:
> > > York,
> > >
> > > The calling code expects the data length in data[0], and the actual
On Wed, 2011-11-16 at 20:10 +0100, Jean Delvare wrote:
> On Wed, 16 Nov 2011 10:20:38 -0800, York Sun wrote:
> > On Wed, 2011-11-16 at 19:09 +0100, Jean Delvare wrote:
> > > Your thinking is too focused on I2C block reads (or even block read of
> > > data over the netwo
On Wed, 2011-11-16 at 20:18 +0100, Jean Delvare wrote:
> On Wed, 16 Nov 2011 11:15:15 -0800, York Sun wrote:
> > On Wed, 2011-11-16 at 20:10 +0100, Jean Delvare wrote:
> > > On Wed, 16 Nov 2011 10:20:38 -0800, York Sun wrote:
> > > > On Wed, 2011-11-16 at 1
> > That's the point. Your patch doesn't check if the length is valid. You
> > rely on the caller to know no more than 32 bytes can be transferred. It
> > shouldn't limit the subfunction to transfer more than 32 bytes if
> > hardware can support it by multiple transactions. If not, print out an
> >
It is safe to apply to all of them
for mpc_i2c_fixup().
Signed-off-by: York Sun
Reviewed-by: Wood Scott-B07421
Reviewed-by: Fleming Andrew-AFLEMING
Tested-by: Fleming Andrew-AFLEMING
CC: linux-i2c@vger.kernel.org
---
drivers/i2c/busses/i2c-mpc.c | 11 ++-
1 file changed, 10 insertions(
It is safe to apply to all of them
for mpc_i2c_fixup().
Signed-off-by: York Sun
---
Change log:
v2: remote reviewed-by and tested-by lines added by gerrit
send to proper mailing list
drivers/i2c/busses/i2c-mpc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --
On 09/16/2013 03:06 PM, York Sun wrote:
> Erratum A-006037 indicates I2C controller executes the write to I2CCR only
> after it sees SCL idle for 64K cycle of internal I2C controller clocks. If
> during this waiting period, I2C controller is disabled (I2CCR[MEN] set to
> 0), then th
On 09/23/2013 12:10 AM, Wolfram Sang wrote:
>
>> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
>> index b80c768..55dce43 100644
>> --- a/drivers/i2c/busses/i2c-mpc.c
>> +++ b/drivers/i2c/busses/i2c-mpc.c
>> @@ -106,7 +106,12 @@ static irqreturn_t mpc_i2c_isr(int irq, voi
On 09/23/2013 03:09 PM, Wolfram Sang wrote:
>
>>> Please, no unnecessary #ifdefs in code. We have 'struct mpc_i2c_data'
>>> already.
>>>
>>
>> I am not pround of this change. Please elaborate how to use mpc_i2c_data
>> to separate the mpc85xx from the rest.
>
> Search for 'match->data' and see ho
On 09/23/2013 03:32 PM, Wolfram Sang wrote:
>
>> I see. It is using device tree to match. But the device tree doesn't
>> have enough information. Many platforms don't specifiy if compatible
>> with mpc85xx, so they fall into .compatible = "fsl-i2c".
>
> :( Can those be fixed to use proper "fsl,m
Julia and other experts,
I am seeking for help on my device driver.
I am working on a module driver for a FPGA design with open core I2C controller
memory-mapped to BAR2. I have searched up and down and found only one driver
(drivers/mfd/timberdale.c) with similar implementation. Following timber
Resend to LKML
Lee,
This question is actually more about MFD. Can you point me to the possible
causes for my failure below?
Thanks.
York
On 04/16/2015 05:02 PM, York Sun wrote:
> Julia and other experts,
>
> I am seeking for help on my device driver.
>
> I am working on a mo
On 04/19/2015 11:42 PM, Lee Jones wrote:
> On Fri, 17 Apr 2015, York Sun wrote:
>
>> Resend to LKML
>>
>> Lee,
>>
>> This question is actually more about MFD. Can you point me to the possible
>> causes for my failure below?
>
> It's hard t
On 04/20/2015 11:16 AM, Lee Jones wrote:
> On Mon, 20 Apr 2015, York Sun wrote:
>
>>
>>
>> On 04/19/2015 11:42 PM, Lee Jones wrote:
>>> On Fri, 17 Apr 2015, York Sun wrote:
>>>
>>>> Resend to LKML
>>>>
>>>> Lee,
>&g
Lee,
Is there any convention regarding I2C class bitmask? I see only three are
defined for 3.12.19 and four for 4.0
I2C_CLASS_HWMON, I2C_CLASS_DDC, I2C_CLASS_SPD, I2C_CLASS_DEPRECATED
I am working on a clock chip driver (SI5338) and trying to detect them (multiple
chips in i2c mux). It would be
On 05/23/2015 09:27 AM, Guenter Roeck wrote:
> On Thu, May 21, 2015 at 02:07:31PM -0700, York Sun wrote:
>> Lee,
>>
>> Is there any convention regarding I2C class bitmask? I see only three are
>> defined for 3.12.19 and four for 4.0
>>
>> I2C_CL
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
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&
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/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
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 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 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 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 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: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
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
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?
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
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
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
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
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
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
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
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
__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 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
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/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;
>
.
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
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
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
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 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 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-i2c" in
the body of a message to majord
.
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/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:
v5: Remove variable initial_state
Remove .owner = THIS_MODULE
v4: Rename no-read to write-only
Revise binding document
Revise endianness checking
Reorder
-R58495
Subject: [PATCH] i2c: mux: reg: simplify register size checking
Checking was done at three different locations, just do it once and
properly at probing time.
Signed-off-by: Wolfram Sang
Cc: York Sun
---
York Sun: Can you test this patch? I can only build test.
drivers/i2c/muxes/i2c-mux
On 08/31/2015 03:24 PM, Wolfram Sang wrote:
> On Fri, Aug 21, 2015 at 03:26:23AM +0000, York Sun wrote:
>> Sorry for top posting, I am out and replying using web access.
>>
>> This patch looks OK. I cannot test it until earliest next Friday.
>
> Did you have the
On 08/20/2015 04:40 PM, Wolfram Sang wrote:
> Checking was done at three different locations, just do it once and
> properly at probing time.
>
> Signed-off-by: Wolfram Sang
> Cc: York Sun
> ---
>
> York Sun: Can you test this patch? I can only build test.
Patch is
Reading the register (if allowed) after writing is to ensure writing
is completed on a posted bus. The endianness of reading doesn't matter.
Signed-off-by: York Sun
---
drivers/i2c/muxes/i2c-mux-reg.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
Peter,
I have a platform (FPGA) with multiple ocores i2c adapter. When I register them
using MFD framework, I got a message regarding duplicating name for sysfs. I
wonder if this driver (i2c-ocores.c) only supports one adapter. I can try to
fix it by adding a name string into ocores_i2c_platfo
Peter,
On 10/01/2015 11:03 PM, Peter Korsgaard wrote:
>>>>>> "York" == York Sun writes:
>
> > Peter,
>
> > I have a platform (FPGA) with multiple ocores i2c adapter. When I
> > register them using MFD framework, I got a message regardi
Split existing API i2c_new_device(), i2c_new_probed_device() into
two halves. The first half creates new i2c devices and the second
half calls device_register(). It allows additional work to be done
before registering the device.
Signed-off-by: York Sun
CC: Wolfram Sang
CC: Stephen Boyd
59 matches
Mail list logo
