* Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 20:58 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170112174902.j52foglkdouyz36n-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-01-12 18:49 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> > Hello Cedric,
>> >
>> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> >> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> >> > uncomfortable.
>> >> >>
>> >> >> I agree but this exactly the hardware way of working described in the
>> >> >> reference manual.
>> >> >
>> >> > IMHO that's a hw bug. This makes it for example impossible to implement
>> >> > SMBus block transfers (I think).
>> >>
>> >> This is not correct.
>> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> by I2C specification.
>> >> So SMBus block transfer will be possible.
>> >
>> > A block transfer consists of a byte that specifies the count of bytes
>> > yet to come. So the device sends for example:
>> >
>> > 0x01 0xab
>> >
>> > So when you read the 1 in the first byte it's already too late to set
>> > STOP to get it after the 2nd byte.
>> >
>> > Not sure I got all the required details right, though.
>>
>> Ok I understand your use case but I always think that the harware manages it.
>> If I take the above example, the I2C SMBus block read transaction will
>> be as below:
>> S Addr Wr [A] Comm [A]
>> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>>
>> The first message is a single byte-transmission so there is no problem.
>>
>> The second message is a N-byte reception with N = 3
>>
>> When the I2C controller has finished to send the device address (S
>> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> In the routine that handles ADDR event, we set ACK bit in order to
>> generate ACK pulse as soon as a data byte is received in the shift
>> register and then we clear the ADDR flag.
>> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> So, as far I understand, the device could not sent any data as long as
>> the SCL line is stretched low. Right ?
>>
>> Then, as soon as the SCL line is high, the device could send the first
>> data byte (Count).
>> When this byte is received in the shift register, an ACK is
>> automatically generated as defined during adress match phase and the
>> data byte is pushed in DR (data register).
>> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> In the routine that handles RXNE event, as N=3, we just clear all
>> buffer interrupts in order to avoid another system preemption due to
>> RXNE event but we does not read the data in DR.
>
> In my example I want to receive a block of length 1, so only two bytes
> are read, a 1 (the length) and the data byte (0xab in my example). I
> think that as soon as you read the 1 it's already to late to schedule
> the NA after the next byte?
Not really. This 2-byte reception is also correctly managed.
Indeed, in this case, when the controller has sent the device address,
the ADDR flag is set and an interrupt is raised.
So, as long as the ADDR flag is not cleared, the SCL line is stretched
low and the device could not send any data.
During this address match phase, for a 2-byte reception, we enable
NACK and set POS bit (ACK/NACK position).
As POS=1, the NACK will be sent for the next byte which will be
received in the shift register instead of the current one.
So in this example, the next byte will be the last one.
After that, we clear the ADDR flag and the device is allowed to send data.
When the first data is received in the shift register, the RXNE flag
is set and an interrupt is raised.
As it is a 2-byte reception, we just clear all interrupts buffer to
avoid another preemption due to RXNE but we does not read DR.
Then, the second and last byte is received in the shift register.
The NACK is automatically sent by I2C controller as it was configured
to do that in the address match phase described above.
Moereover, as the first byte has not been read in DR, the BTF event
flag is set and an interrupt is raised.
Again, the SCL line is stretching low as long as data register has not
been read.
In the meantime, we set STOP bit to generate the pulse and we launch 2
consecutive read of DR to retrieve the 2 data bytes and release SCL
stretching.
In that way, NA and STOP are generated as expected even for a 2-byte reception.
Best regards,
Cedric
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 0/5] PCI: exynos: use the PHY generic framework
From: Bjorn Helgaas @ 2017-01-12 21:01 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, krzk, kishon, jingoohan1,
vivek.gautam, pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-1-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:30PM +0900, Jaehoon Chung wrote:
> This patchset is for using PHY generic framework.
> Current pci-exyons doesn't use the phy framework since there haven't been on
> PHY subsystem when Exynos5440 had been upstremed.
> The not using PHY framework make the difficult to upstream the other
> Exynos SoCs.
>
> Before upstreaming the other Exynos SoCs, it's goal what make to use the PHY framework.
>
> This patchset has the below modifications:
> 1) Introduces the phy-pcie-pcie
> 2) Handles Phy controller from PHY framework for pci-exynos
> 3) Modifies the dt-binding of pci-exynos
> - The using the getting configuration space address from ranges is old.
> - Deprecated the old way.
> 4) Maintains the backward compatibility
>
> NOTE: These patches based on below patches:
> http://patchwork.ozlabs.org/patch/706998/
> http://patchwork.ozlabs.org/patch/706997/
> http://patchwork.ozlabs.org/patch/706995/
> http://patchwork.ozlabs.org/patch/706994/
> http://patchwork.ozlabs.org/patch/703530/
> - This patch should be conflicted. so fixes the manually.
> http://patchwork.ozlabs.org/patch/708414/
>
> Changelog on V2:
> - Keep current codes for backward compatibility
> - Fixes some typos
> - Split the patches for removing the dependency
> - Removes the unnecessary codes
> - Change the patch's sequence
> - Based on latest PCI git repository.(next branch)
>
> Jaehoon Chung (5):
> Documetation: samsung-phy: add the exynos-pcie-phy binding
> phy: phy-exynos-pcie: Add support for Exynos PCIe phy
> Documetation: binding: modify the exynos5440 pcie binding
> PCI: exynos: support the using PHY generic framework
> ARM: dts: exynos5440: support the phy-pcie node for pcie
Since you're going to update this, please fix the typos in the above,
e.g., s/Documetation/Documentation/.
In addition, please run "git log --oneline" on the files you're
changing and make your subject lines consistent in style and
capitalization with previous ones, e.g., use "PCIe" consistently.
"Modify the ..." contains no useful information. Of course a patch
modifies something -- please tell us what the modification is useful
for.
> .../bindings/pci/samsung,exynos5440-pcie.txt | 29 +++
> .../devicetree/bindings/phy/samsung-phy.txt | 17 ++
> arch/arm/boot/dts/exynos5440.dtsi | 34 ++-
> drivers/pci/host/pci-exynos.c | 61 ++++-
> drivers/phy/Kconfig | 9 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos-pcie.c | 280 +++++++++++++++++++++
> 7 files changed, 408 insertions(+), 23 deletions(-)
> create mode 100644 drivers/phy/phy-exynos-pcie.c
>
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-12 21:10 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: devicetree, Alexandre Torgue, Wolfram Sang, linux-kernel,
Linus Walleij, Patrice Chotard, Russell King, Rob Herring,
linux-i2c, Maxime Coquelin, linux-arm-kernel
In-Reply-To: <CAOAejn3tPi0fjy+t-UhMTvAq7LfdKJJdbcLw2su1-YAGDZMxew@mail.gmail.com>
On Thu, Jan 12, 2017 at 09:58:23PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-12 18:49 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
> >> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> >> > Hello Cedric,
> >> >
> >> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
> >> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> >> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
> >> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> >> >> >> > This is surprising. I didn't recheck the manual, but that looks very
> >> >> >> > uncomfortable.
> >> >> >>
> >> >> >> I agree but this exactly the hardware way of working described in the
> >> >> >> reference manual.
> >> >> >
> >> >> > IMHO that's a hw bug. This makes it for example impossible to implement
> >> >> > SMBus block transfers (I think).
> >> >>
> >> >> This is not correct.
> >> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
> >> >> Here we have just to prepare the hardware for the 2 next pulse but the
> >> >> STOP/START/ACK pulse will be generated at the right time as required
> >> >> by I2C specification.
> >> >> So SMBus block transfer will be possible.
> >> >
> >> > A block transfer consists of a byte that specifies the count of bytes
> >> > yet to come. So the device sends for example:
> >> >
> >> > 0x01 0xab
> >> >
> >> > So when you read the 1 in the first byte it's already too late to set
> >> > STOP to get it after the 2nd byte.
> >> >
> >> > Not sure I got all the required details right, though.
> >>
> >> Ok I understand your use case but I always think that the harware manages it.
> >> If I take the above example, the I2C SMBus block read transaction will
> >> be as below:
> >> S Addr Wr [A] Comm [A]
> >> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
> >>
> >> The first message is a single byte-transmission so there is no problem.
> >>
> >> The second message is a N-byte reception with N = 3
> >>
> >> When the I2C controller has finished to send the device address (S
> >> Addr Rd), the ADDR flag is set and an interrupt is raised.
> >> In the routine that handles ADDR event, we set ACK bit in order to
> >> generate ACK pulse as soon as a data byte is received in the shift
> >> register and then we clear the ADDR flag.
> >> Please note that the SCL line is stretched low until ADDR flag is cleared.
> >> So, as far I understand, the device could not sent any data as long as
> >> the SCL line is stretched low. Right ?
> >>
> >> Then, as soon as the SCL line is high, the device could send the first
> >> data byte (Count).
> >> When this byte is received in the shift register, an ACK is
> >> automatically generated as defined during adress match phase and the
> >> data byte is pushed in DR (data register).
> >> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
> >> In the routine that handles RXNE event, as N=3, we just clear all
> >> buffer interrupts in order to avoid another system preemption due to
> >> RXNE event but we does not read the data in DR.
> >
> > In my example I want to receive a block of length 1, so only two bytes
> > are read, a 1 (the length) and the data byte (0xab in my example). I
> > think that as soon as you read the 1 it's already to late to schedule
> > the NA after the next byte?
>
> Not really. This 2-byte reception is also correctly managed.
> Indeed, in this case, when the controller has sent the device address,
> the ADDR flag is set and an interrupt is raised.
> So, as long as the ADDR flag is not cleared, the SCL line is stretched
> low and the device could not send any data.
> During this address match phase, for a 2-byte reception, we enable
> NACK and set POS bit (ACK/NACK position).
> As POS=1, the NACK will be sent for the next byte which will be
> received in the shift register instead of the current one.
> So in this example, the next byte will be the last one.
> After that, we clear the ADDR flag and the device is allowed to send data.
I didn't follow, but if you are convinced it works that's good. I wonder
if it simplifies the driver if POS=1 is used and so ACK/NACK can be
setup later?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 21:28 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170112211004.z3wylc7vrubulc3x-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-01-12 22:10 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Thu, Jan 12, 2017 at 09:58:23PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 18:49 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> > On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> >> > Hello Cedric,
>> >> >
>> >> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> >> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> >> >> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> >> >> > uncomfortable.
>> >> >> >>
>> >> >> >> I agree but this exactly the hardware way of working described in the
>> >> >> >> reference manual.
>> >> >> >
>> >> >> > IMHO that's a hw bug. This makes it for example impossible to implement
>> >> >> > SMBus block transfers (I think).
>> >> >>
>> >> >> This is not correct.
>> >> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> >> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> >> by I2C specification.
>> >> >> So SMBus block transfer will be possible.
>> >> >
>> >> > A block transfer consists of a byte that specifies the count of bytes
>> >> > yet to come. So the device sends for example:
>> >> >
>> >> > 0x01 0xab
>> >> >
>> >> > So when you read the 1 in the first byte it's already too late to set
>> >> > STOP to get it after the 2nd byte.
>> >> >
>> >> > Not sure I got all the required details right, though.
>> >>
>> >> Ok I understand your use case but I always think that the harware manages it.
>> >> If I take the above example, the I2C SMBus block read transaction will
>> >> be as below:
>> >> S Addr Wr [A] Comm [A]
>> >> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>> >>
>> >> The first message is a single byte-transmission so there is no problem.
>> >>
>> >> The second message is a N-byte reception with N = 3
>> >>
>> >> When the I2C controller has finished to send the device address (S
>> >> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> >> In the routine that handles ADDR event, we set ACK bit in order to
>> >> generate ACK pulse as soon as a data byte is received in the shift
>> >> register and then we clear the ADDR flag.
>> >> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> >> So, as far I understand, the device could not sent any data as long as
>> >> the SCL line is stretched low. Right ?
>> >>
>> >> Then, as soon as the SCL line is high, the device could send the first
>> >> data byte (Count).
>> >> When this byte is received in the shift register, an ACK is
>> >> automatically generated as defined during adress match phase and the
>> >> data byte is pushed in DR (data register).
>> >> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> >> In the routine that handles RXNE event, as N=3, we just clear all
>> >> buffer interrupts in order to avoid another system preemption due to
>> >> RXNE event but we does not read the data in DR.
>> >
>> > In my example I want to receive a block of length 1, so only two bytes
>> > are read, a 1 (the length) and the data byte (0xab in my example). I
>> > think that as soon as you read the 1 it's already to late to schedule
>> > the NA after the next byte?
>>
>> Not really. This 2-byte reception is also correctly managed.
>> Indeed, in this case, when the controller has sent the device address,
>> the ADDR flag is set and an interrupt is raised.
>> So, as long as the ADDR flag is not cleared, the SCL line is stretched
>> low and the device could not send any data.
>> During this address match phase, for a 2-byte reception, we enable
>> NACK and set POS bit (ACK/NACK position).
>> As POS=1, the NACK will be sent for the next byte which will be
>> received in the shift register instead of the current one.
>> So in this example, the next byte will be the last one.
>> After that, we clear the ADDR flag and the device is allowed to send data.
>
> I didn't follow, but if you are convinced it works that's good. I wonder
> if it simplifies the driver if POS=1 is used and so ACK/NACK can be
> setup later?
Please see below a quote from datasheet that clearly described how to handle
For 2-byte reception:
● Wait until ADDR = 1 (SCL stretched low until the ADDR flag is cleared)
● Set ACK low, set POS high
● Clear ADDR flag
● Wait until BTF = 1 (Data 1 in DR, Data2 in shift register, SCL
stretched low until a data1 is read)
● Set STOP high
● Read data 1 and 2
So we cannot set POS=1 and setup ACK/NACK later as you suggest.
Best regards,
Cedric
--
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
* [PATCH v2 00/18] FSI device driver introduction
From: christopher.lee.bostic @ 2017-01-12 21:54 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel
Cc: joel, jk, linux-kernel, andrew, alistair, benh, Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (8):
drivers/fsi: Kick off master scan via sysfs
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Remove all scanned devices during master unregister
drivers/fsi: Add FSI bus documentation
drivers/fsi: Add documentation for GPIO based FSI master
drivers/fsi: Document FSI master sysfs files in ABI
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (10):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add FSI crc calculators to library
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
Changes for v2:
- Change from atomic global for master number to ida simple
interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
instead the device_for_each_child method available in the
bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
implementing it.
- Document all comptible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interfac for all optional GPIO pins.
Documentation/ABI/testing/sysfs-bus-fsi | 6 +
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 +++
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 23 +
drivers/fsi/Makefile | 3 +
drivers/fsi/fsi-core.c | 494 +++++++++++++++++++
drivers/fsi/fsi-master-gpio.c | 530 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 39 ++
include/linux/crc-fsi.h | 29 ++
include/linux/fsi.h | 60 +++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 ++
14 files changed, 1352 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/crc-fsi.h
create mode 100644 include/linux/fsi.h
create mode 100644 lib/crc-fsi.c
--
1.8.2.2
^ permalink raw reply
* Re: [PATCH v3] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Bjorn Helgaas @ 2017-01-12 21:57 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Rob Herring, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484185997-55685-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Jan 12, 2017 at 09:53:17AM +0800, Shawn Lin wrote:
> Rockchip's RC outputs 100MHz reference clock but there are
> two methods for PHY to generate it.
>
> (1)One of them is to use system PLL to generate 100MHz clock and
> the PHY will relock it and filter signal noise then outputs the
> reference clock.
>
> (2)Another way is to share Soc's 24MHZ crystal oscillator with
> PHY and force PHY's DLL to generate 100MHz internally.
>
> When using case(2), the exit from L0s doesn't work fine occasionally
> due to the broken design of RC receiver's logical circuit. So even if
> we use extended-synch, it still fails for PHY to relock the bits from
> FTS sometimes. This will hang the system.
>
> Maybe we could argue that why not use case(1) to avoid it? The reason
> is that as we could see the reference clock is derived from system PLL
> and the path from it to PHY isn't so clean which means there are some
> noise introduced by power-domain and other buses can't be filterd out
> by PHY and we could see noise from the frequency spectrum by
> oscilloscope. This makes the TX compatibility test a little difficult
> to pass the spec. So case(1) and case(2) are both used indeed now. If
> using case(2), we should disable RC's L0s support, and that is why we
> need this property to indicate this quirk.
>
> Also after checking quirk.c, I noticed there is already a quirk for
> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
> shouldn't do that as mentioned above that case(1) could still works fine
> with L0s.
>
> Reported-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Cc: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
I applied this to pci/host-rockchip for v4.11. I added Brian's Reviewed-by
and Rob's Acked-by, since you didn't change anything substantive.
I assume there's no way to automatically discover whether the system is
using the 24MHz oscillator? If there is a way, we should use that instead
of requiring a DT property.
I reworded the changelog; I hope it still make sense:
PCI: rockchip: Disable RC's ASPM L0s based on DT "aspm-no-l0s"
Rockchip's RC produces a 100MHz reference clock but there are two methods
for the PHY to generate it:
(1) Use the system PLL to generate a 100MHz clock. The PHY will relock
it, filter signal noise, and output the reference clock. ASPM L0s
works correctly, but circuit noise issues make it difficult to pass
the TX compatibility test.
(2) Share the SoC's 24MHZ crystal oscillator with the PHY and force the
PHY's PLL to generate 100MHz internally. In this case, exit from
ASPM L0s sometimes fails due to a design error in the RC receiver
circuit. Even if we use extended-synch, the PHY sometimes fails to
relock the bits from FTS, which will hang the system.
We want the flexibility to use both clocking methods, so add a DT property,
"aspm-no-l0s". If that's present, disable L0s to avoid the issues with
case (2).
[bhelgaas: changelog]
Reported-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Signed-off-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v3:
> - fix misspelled aspm for the property name
>
> Changes in v2:
> - drop the quirk prefix
>
> Documentation/devicetree/bindings/pci/rockchip-pcie.txt | 2 ++
> drivers/pci/host/pcie-rockchip.c | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> index 71aeda1..1453a73 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -43,6 +43,8 @@ Required properties:
> - interrupt-map-mask and interrupt-map: standard PCI properties
>
> Optional Property:
> +- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
> + using 24MHz OSC for RC's PHY.
> - ep-gpios: contain the entry for pre-reset gpio
> - num-lanes: number of lanes to use
> - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index f2dca7b..140cdc7 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -140,6 +140,8 @@
> #define PCIE_RC_CONFIG_DCR_CSPL_SHIFT 18
> #define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> #define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> +#define PCIE_RC_CONFIG_LINK_CAP (PCIE_RC_CONFIG_BASE + 0xcc)
> +#define PCIE_RC_CONFIG_LINK_CAP_L0S BIT(10)
> #define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> #define PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2 (PCIE_RC_CONFIG_BASE + 0x90c)
> #define PCIE_RC_CONFIG_THP_CAP (PCIE_RC_CONFIG_BASE + 0x274)
> @@ -653,6 +655,13 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> status &= ~PCIE_RC_CONFIG_THP_CAP_NEXT_MASK;
> rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_THP_CAP);
>
> + /* Clear L0s from RC's link cap */
> + if (of_property_read_bool(dev->of_node, "aspm-no-l0s")) {
> + status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_LINK_CAP);
> + status &= ~PCIE_RC_CONFIG_LINK_CAP_L0S;
> + rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_LINK_CAP);
> + }
> +
> rockchip_pcie_write(rockchip, 0x0, PCIE_RC_BAR_CONF);
>
> rockchip_pcie_write(rockchip,
> --
> 1.9.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Stephen Boyd @ 2017-01-12 22:05 UTC (permalink / raw)
To: Jacky Bai
Cc: shawnguo@kernel.org, mturquette@baylibre.com, robh+dt@kernel.org,
mark.rutland@arm.com, linus.walleij@linaro.org,
kernel@pengutronix.de, Fabio Estevam, daniel.lezcano@linaro.org,
tglx@linutronix.de, p.zabel@pengutronix.de,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
jacky.baip@gmail.com
In-Reply-To: <AM3PR04MB5307CB38AA904535AF8D80D87670@AM3PR04MB530.eurprd04.prod.outlook.com>
On 01/10, Jacky Bai wrote:
>
> >
> > > +#include <linux/types.h>
> > > +
> > > +#include "clk.h"
> > > +
> > > +#define CCM_ANALOG_PLL_BYPASS (0x1 << 16)
> > > +#define BM_CCM_CCDR_MMDC_CH0_MASK (0x2 << 16)
> > > +#define CCDR 0x4
> > > +#define xPLL_CLR(offset) (offset + 0x8)
> > > +
> > > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> >
> > All these should be const char * const unless something is wrong.
>
> If changed to 'const char * const', it vill has argument type mismatch error, as imx_clk_* wrapper function
> has argument type 'const char *'.
Hmm that's unfortunate.
>
> >
> > > +static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src",
> > > +}; static const char *pll2_bypass_sels[] = { "pll2",
> > > +"pll2_bypass_src", }; static const char *pll3_bypass_sels[] = {
> > > +"pll3", "pll3_bypass_src", }; static const char *pll4_bypass_sels[] =
> > > +{ "pll4", "pll4_bypass_src", }; static const char *pll5_bypass_sels[]
> > > += { "pll5", "pll5_bypass_src", }; static const char
> > > +*pll6_bypass_sels[] = { "pll6", "pll6_bypass_src", };
> > [...]
> > > + clks[IMX6SLL_CLK_USDHC3] = imx_clk_gate2("usdhc3",
> > "usdhc3_podf", base + 0x80, 6);
> > > +
> > > + /* mask handshake of mmdc */
> > > + writel_relaxed(BM_CCM_CCDR_MMDC_CH0_MASK, base + CCDR);
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(clks); i++)
> > > + if (IS_ERR(clks[i]))
> > > + pr_err("i.MX6SLL clk %d: register failed with %ld\n", i,
> > > +PTR_ERR(clks[i]));
> > > +
> > > + clk_data.clks = clks;
> > > + clk_data.clk_num = ARRAY_SIZE(clks);
> > > + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> > > +
> > > + /* set perclk to from OSC */
> > > + clk_set_parent(clks[IMX6SLL_CLK_PERCLK_SEL],
> > clks[IMX6SLL_CLK_OSC]);
> >
> > Can this be done with assigned-clocks in DT?
>
> Ok, I will move it to assigned-clocks in DT.
>
> >
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > + clk_prepare_enable(clks[clks_init_on[i]]);
> >
> > Critical clocks?
>
> Yes, these clocks must be always on.
>
> >
> > > +
> > > + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
> >
> > The phy driver can't enable these?
>
> The reason why we enable these two clks here is in below commit
> commit a5120e89e7e187a91852896f586876c7a2030804
> Author: Peter Chen <peter.chen@freescale.com>
> Date: Fri Jan 18 10:38:05 2013 +0800
> ARM i.MX6: change mxs usbphy clock usage
>
So can we mark these clks with CLK_IS_CRITICAL flag then instead?
Or are they disabled out of the bootloader?
> >
> > > + }
> > > +
> > > + /* Lower the AHB clock rate before changing the clock source. */
> > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> > > +
> > > + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL],
> > clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > clks[IMX6SLL_CLK_PERIPH_CLK2]);
> > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE],
> > clks[IMX6SLL_CLK_PLL2_BUS]);
> > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > +clks[IMX6SLL_CLK_PERIPH_PRE]);
> > > +
> > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
> >
> > assigned-clocks for rates now? Or perhaps we shouldn't be exposing these as
> > clks if they have some sort of complicated rate sequence switch that we can't
> > guarantee with the clk_ops we have today.
>
> These clks will be used by some peripherals, so we need to expose these clocks.
> And the above parent and rate swith sequence is not very easy to be handled in assigned-clocks,
> So we leave it in this place.
>
How do we guarantee that the rate switch doesn't happen later on,
requiring this coordinated sequence of clk operations?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 01/18] drivers/fsi: Add device & driver definitions
From: christopher.lee.bostic @ 2017-01-12 22:14 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
Add structs for fsi devices & drivers, and struct device conversion
functions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
include/linux/fsi.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index 47aa181..f73886a 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -17,6 +17,17 @@
#include <linux/device.h>
+struct fsi_device {
+ struct device dev;
+};
+
+struct fsi_driver {
+ struct device_driver drv;
+};
+
+#define to_fsi_dev(devp) container_of(devp, struct fsi_device, dev)
+#define to_fsi_drv(drvp) container_of(drvp, struct fsi_driver, drv)
+
extern struct bus_type fsi_bus_type;
#endif /* LINUX_FSI_H */
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 02/18] drivers/fsi: add driver to device matches
From: christopher.lee.bostic @ 2017-01-12 22:21 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
Driver bind to devices based on the engine types & (optional) versions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 21 +++++++++++++++++++++
include/linux/fsi.h | 21 +++++++++++++++++++--
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 3e45306..3d55bd5 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -19,8 +19,29 @@
/* FSI core & Linux bus type definitions */
+static int fsi_bus_match(struct device *dev, struct device_driver *drv)
+{
+ struct fsi_device *fsi_dev = to_fsi_dev(dev);
+ struct fsi_driver *fsi_drv = to_fsi_drv(drv);
+ const struct fsi_device_id *id;
+
+ if (!fsi_drv->id_table)
+ return 0;
+
+ for (id = fsi_drv->id_table; id->engine_type; id++) {
+ if (id->engine_type != fsi_dev->engine_type)
+ continue;
+ if (id->version == FSI_VERSION_ANY ||
+ id->version == fsi_dev->version)
+ return 1;
+ }
+
+ return 0;
+}
+
struct bus_type fsi_bus_type = {
.name = "fsi",
+ .match = fsi_bus_match,
};
EXPORT_SYMBOL_GPL(fsi_bus_type);
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index f73886a..273cbf6 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -18,11 +18,28 @@
#include <linux/device.h>
struct fsi_device {
- struct device dev;
+ struct device dev;
+ u8 engine_type;
+ u8 version;
};
+struct fsi_device_id {
+ u8 engine_type;
+ u8 version;
+};
+
+#define FSI_VERSION_ANY 0
+
+#define FSI_DEVICE(t) \
+ .engine_type = (t), .version = FSI_VERSION_ANY,
+
+#define FSI_DEVICE_VERSIONED(t, v) \
+ .engine_type = (t), .version = (v),
+
+
struct fsi_driver {
- struct device_driver drv;
+ struct device_driver drv;
+ const struct fsi_device_id *id_table;
};
#define to_fsi_dev(devp) container_of(devp, struct fsi_device, dev)
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 03/18] drivers/fsi: Add fsi master definition
From: christopher.lee.bostic @ 2017-01-12 22:24 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Change atomic global keeping track of master number to ida
simple interface.
- Add valid pointer checks on entry to register and unregister.
---
drivers/fsi/fsi-core.c | 28 ++++++++++++++++++++++++++++
drivers/fsi/fsi-master.h | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 drivers/fsi/fsi-master.h
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 3d55bd5..c7469fe 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -16,6 +16,34 @@
#include <linux/device.h>
#include <linux/fsi.h>
#include <linux/module.h>
+#include <linux/idr.h>
+
+#include "fsi-master.h"
+
+static DEFINE_IDA(master_ida);
+
+/* FSI master support */
+
+int fsi_master_register(struct fsi_master *master)
+{
+ if (!master || !master->dev)
+ return -EINVAL;
+
+ master->idx = ida_simple_get(&master_ida, 0, 0, GFP_KERNEL);
+ get_device(master->dev);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fsi_master_register);
+
+void fsi_master_unregister(struct fsi_master *master)
+{
+ if (!master || !master->dev)
+ return;
+
+ ida_simple_remove(&master_ida, master->idx);
+ put_device(master->dev);
+}
+EXPORT_SYMBOL_GPL(fsi_master_unregister);
/* FSI core & Linux bus type definitions */
diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
new file mode 100644
index 0000000..e75a810
--- /dev/null
+++ b/drivers/fsi/fsi-master.h
@@ -0,0 +1,37 @@
+/*
+ * FSI master definitions. These comprise the core <--> master interface,
+ * to allow the core to interact with the (hardware-specific) masters.
+ *
+ * Copyright (C) IBM Corporation 2016
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef DRIVERS_FSI_MASTER_H
+#define DRIVERS_FSI_MASTER_H
+
+#include <linux/device.h>
+
+struct fsi_master {
+ struct device *dev;
+ int idx;
+ int n_links;
+ int (*read)(struct fsi_master *, int link,
+ uint8_t slave, uint32_t addr,
+ void *val, size_t size);
+ int (*write)(struct fsi_master *, int link,
+ uint8_t slave, uint32_t addr,
+ const void *val, size_t size);
+};
+
+extern int fsi_master_register(struct fsi_master *master);
+extern void fsi_master_unregister(struct fsi_master *master);
+
+#endif /* DRIVERS_FSI_MASTER_H */
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 04/18] drivers/fsi: Add slave definition
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 22:25 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
Cc: Chris Bostic
From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Add the initial fsi slave device, which is private to the core code.
This will be a child of the master, and parent to endpoint devices.
Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
drivers/fsi/fsi-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index c7469fe..78d9c558 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -22,6 +22,15 @@
static DEFINE_IDA(master_ida);
+struct fsi_slave {
+ struct device dev;
+ struct fsi_master *master;
+ int link;
+ uint8_t id;
+};
+
+#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
+
/* FSI master support */
int fsi_master_register(struct fsi_master *master)
--
1.8.2.2
--
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 related
* [PATCH v2 05/18] drivers/fsi: Add empty master scan
From: christopher.lee.bostic @ 2017-01-12 22:26 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
When a new fsi master is added, we will need to scan its links, and
slaves attached to those links. This change introduces a little shell to
iterate the links, which we will populate with the actual slave scan in
a later change.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 78d9c558..3160c1c 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -20,6 +20,8 @@
#include "fsi-master.h"
+#define FSI_N_SLAVES 4
+
static DEFINE_IDA(master_ida);
struct fsi_slave {
@@ -31,8 +33,29 @@ struct fsi_slave {
#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
+/* FSI slave support */
+static int fsi_slave_init(struct fsi_master *master,
+ int link, uint8_t slave_id)
+{
+ /* todo: initialise slave device, perform engine scan */
+
+ return -ENODEV;
+}
+
/* FSI master support */
+static int fsi_master_scan(struct fsi_master *master)
+{
+ int link, slave_id;
+
+ for (link = 0; link < master->n_links; link++)
+ for (slave_id = 0; slave_id < FSI_N_SLAVES; slave_id++)
+ fsi_slave_init(master, link, slave_id);
+
+ return 0;
+
+}
+
int fsi_master_register(struct fsi_master *master)
{
if (!master || !master->dev)
@@ -40,6 +63,7 @@ int fsi_master_register(struct fsi_master *master)
master->idx = ida_simple_get(&master_ida, 0, 0, GFP_KERNEL);
get_device(master->dev);
+ fsi_master_scan(master);
return 0;
}
EXPORT_SYMBOL_GPL(fsi_master_register);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 06/18] drivers/fsi: Add FSI crc calculators to library
From: christopher.lee.bostic @ 2017-01-12 22:27 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
Add some helpers for the crc checks for the slave configuration table.
This works 4-bits-at-a-time, using a simple table approach.
We will need this in the FSI core code, as well as any master
implementations that need to calculate CRCs in software.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Move crc utilities out of the FSI core and move into linux/lib.
---
include/linux/crc-fsi.h | 29 +++++++++++++++++++++++++++++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 69 insertions(+)
create mode 100644 include/linux/crc-fsi.h
create mode 100644 lib/crc-fsi.c
diff --git a/include/linux/crc-fsi.h b/include/linux/crc-fsi.h
new file mode 100644
index 0000000..e96d2f0
--- /dev/null
+++ b/include/linux/crc-fsi.h
@@ -0,0 +1,29 @@
+/*
+ * FSI CRC calculator
+ *
+ * Copyright (C) IBM Corporation 2016
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * Implements the standard FSI CRC:
+ *
+ * Width 1 - 32
+ * Poly 0x0017 (x^4 + x^2 + x^1 + x^0)
+ */
+
+#ifndef CRC_FSI_H
+#define CRC_FSI_H
+
+#include <linux/types.h>
+
+uint8_t crc_fsi(uint8_t c, uint64_t x, int bits);
+
+#endif /* CRC_FSI_H */
diff --git a/lib/Makefile b/lib/Makefile
index 50144a3..c840628 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -230,3 +230,4 @@ obj-$(CONFIG_UBSAN) += ubsan.o
UBSAN_SANITIZE_ubsan.o := n
obj-$(CONFIG_SBITMAP) += sbitmap.o
+obj-$(CONFIG_FSI) += crc-fsi.o
diff --git a/lib/crc-fsi.c b/lib/crc-fsi.c
new file mode 100644
index 0000000..55cfe9d
--- /dev/null
+++ b/lib/crc-fsi.c
@@ -0,0 +1,39 @@
+/*
+ * FSI CRC calculator
+ *
+ * Copyright (C) IBM Corporation 2016
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/crc-fsi.h>
+
+/* crc helpers */
+static const uint8_t crc_fsi_tab[] = {
+ 0x0, 0x7, 0xe, 0x9, 0xb, 0xc, 0x5, 0x2,
+ 0x1, 0x6, 0xf, 0x8, 0xa, 0xd, 0x4, 0x3,
+};
+
+uint8_t crc_fsi(uint8_t c, uint64_t x, int bits)
+{
+ int i;
+
+ /* Align to 4-bits */
+ bits = (bits + 3) & ~0x3;
+
+ /* Calculate crc4 over four-bit nibbles, starting at the MSbit */
+ for (i = bits; i >= 0; i -= 4)
+ c = crc_fsi_tab[c ^ ((x >> i) & 0xf)];
+
+ return c;
+}
+EXPORT_SYMBOL_GPL(crc_fsi);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 07/18] drivers/fsi: Kick off master scan via sysfs
From: christopher.lee.bostic @ 2017-01-12 22:28 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Move master scan from automatic kick off early in kernel power up
to a scan file that can be invoked at any particular time based
on needs of a given platform.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 3160c1c..5f9f7a9 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -53,8 +53,19 @@ static int fsi_master_scan(struct fsi_master *master)
fsi_slave_init(master, link, slave_id);
return 0;
+}
+
+static ssize_t store_scan(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct fsi_master *master = dev_get_drvdata(dev);
+ fsi_master_scan(master);
+ return count;
}
+static DEVICE_ATTR(scan, 0200, NULL, store_scan);
int fsi_master_register(struct fsi_master *master)
{
@@ -63,8 +74,8 @@ int fsi_master_register(struct fsi_master *master)
master->idx = ida_simple_get(&master_ida, 0, 0, GFP_KERNEL);
get_device(master->dev);
- fsi_master_scan(master);
- return 0;
+ dev_set_drvdata(master->dev, master);
+ return device_create_file(master->dev, &dev_attr_scan);
}
EXPORT_SYMBOL_GPL(fsi_master_register);
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH] ARM: dts: am335x-phycore-som: Remove partition tables
From: Tony Lindgren @ 2017-01-12 22:28 UTC (permalink / raw)
To: Teresa Remmet
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Benoît Cousson,
Rob Herring, Mark Rutland, Brian Norris
In-Reply-To: <1483951050-46588-1-git-send-email-t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
* Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> [170109 00:38]:
> As the bootloader passes the NAND and the SPI flash partition tables
> there is no need to keep them in the kernel device tree.
> Removed them.
>
> Signed-off-by: Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
Applying into omap-for-v4.11/dt thanks.
Tony
--
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
* [PATCH v2 08/18] drivers/fsi: Implement slave initialisation
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 22:29 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
Cc: Chris Bostic
From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Create fsi_slave devices during the master scan.
Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
drivers/fsi/fsi-core.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 5f9f7a9..931bcba 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -17,10 +17,15 @@
#include <linux/fsi.h>
#include <linux/module.h>
#include <linux/idr.h>
+#include <linux/crc-fsi.h>
+#include <linux/slab.h>
#include "fsi-master.h"
#define FSI_N_SLAVES 4
+#define FSI_SLAVE_CONF_CRC_SHIFT 4
+#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
+#define FSI_SLAVE_CONF_DATA_BITS 28
static DEFINE_IDA(master_ida);
@@ -34,12 +39,59 @@ struct fsi_slave {
#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
/* FSI slave support */
+
+static void fsi_slave_release(struct device *dev)
+{
+ struct fsi_slave *slave = to_fsi_slave(dev);
+
+ kfree(slave);
+}
+
static int fsi_slave_init(struct fsi_master *master,
int link, uint8_t slave_id)
{
- /* todo: initialise slave device, perform engine scan */
+ struct fsi_slave *slave;
+ uint32_t chip_id;
+ int rc;
+ uint8_t crc;
+
+ rc = master->read(master, link, slave_id, 0, &chip_id, sizeof(chip_id));
+ if (rc) {
+ dev_warn(master->dev, "can't read slave %02x:%02x: %d\n",
+ link, slave_id, rc);
+ return -ENODEV;
+ }
+ crc = crc_fsi(0, chip_id >> FSI_SLAVE_CONF_CRC_SHIFT,
+ FSI_SLAVE_CONF_DATA_BITS);
+ if (crc != (chip_id & FSI_SLAVE_CONF_CRC_MASK)) {
+ dev_warn(master->dev, "slave %02x:%02x invalid chip id CRC!\n",
+ link, slave_id);
+ return -EIO;
+ }
+
+ pr_debug("fsi: found chip %08x at %02x:%02x:%02x\n",
+ master->idx, chip_id, link, slave_id);
+
+ /* we can communicate with a slave; create devices and scan */
+ slave = kzalloc(sizeof(*slave), GFP_KERNEL);
+ if (!slave)
+ return -ENOMEM;
+
+ slave->master = master;
+ slave->id = slave_id;
+ slave->dev.parent = master->dev;
+ slave->dev.release = fsi_slave_release;
+
+ dev_set_name(&slave->dev, "slave@%02x:%02x", link, slave_id);
+ rc = device_register(&slave->dev);
+ if (rc < 0) {
+ dev_warn(master->dev, "failed to create slave device: %d\n",
+ rc);
+ put_device(&slave->dev);
+ return rc;
+ }
- return -ENODEV;
+ return rc;
}
/* FSI master support */
--
1.8.2.2
--
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 related
* Re: [PATCH] ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
From: Tony Lindgren @ 2017-01-12 22:30 UTC (permalink / raw)
To: Jean-Jacques Hiblot; +Cc: bcousson, linux-omap, devicetree, rogerq, stable
In-Reply-To: <1483964535-4298-1-git-send-email-jjhiblot@ti.com>
* Jean-Jacques Hiblot <jjhiblot@ti.com> [170109 04:23]:
> AHCI provides the register PORTS_IMPL to let the software know which port
> is supported. The register must be initialized by the bootloader. However
> in some cases u-boot doesn't properly initialize this value (if it is not
> compiled with SATA support for example or if the SATA initialization fails).
> The DTS entry "ports-implemented" can be used to override the value in
> PORTS_IMPL.
> Adding this entry in the dts allows us no to worry about what is done by
> the bootloader.
Adding into omap-for-v4.11/dt thanks.
Tony
^ permalink raw reply
* [PATCH v2 09/18] drivers/fsi: scan slaves & register devices
From: christopher.lee.bostic @ 2017-01-12 22:30 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Jeremy Kerr <jk@ozlabs.org>
Now that we have fsi_slave devices, scan each for endpoints, and
register them on the fsi bus.
Includes contributions from Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++--
include/linux/fsi.h | 4 ++
2 files changed, 136 insertions(+), 4 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 931bcba..f7ef993 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -23,9 +23,19 @@
#include "fsi-master.h"
#define FSI_N_SLAVES 4
-#define FSI_SLAVE_CONF_CRC_SHIFT 4
-#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
-#define FSI_SLAVE_CONF_DATA_BITS 28
+
+#define FSI_SLAVE_CONF_NEXT_MASK 0x80000000
+#define FSI_SLAVE_CONF_SLOTS_MASK 0x00ff0000
+#define FSI_SLAVE_CONF_SLOTS_SHIFT 16
+#define FSI_SLAVE_CONF_VERSION_MASK 0x0000f000
+#define FSI_SLAVE_CONF_VERSION_SHIFT 12
+#define FSI_SLAVE_CONF_TYPE_MASK 0x00000ff0
+#define FSI_SLAVE_CONF_TYPE_SHIFT 4
+#define FSI_SLAVE_CONF_CRC_SHIFT 4
+#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
+#define FSI_SLAVE_CONF_DATA_BITS 28
+
+static const int engine_page_size = 0x400;
static DEFINE_IDA(master_ida);
@@ -38,8 +48,125 @@ struct fsi_slave {
#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
+/* FSI endpoint-device support */
+
+static void fsi_device_release(struct device *_device)
+{
+ struct fsi_device *device = to_fsi_dev(_device);
+
+ kfree(device);
+}
+
+static struct fsi_device *fsi_create_device(struct fsi_slave *slave)
+{
+ struct fsi_device *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ dev->dev.parent = &slave->dev;
+ dev->dev.bus = &fsi_bus_type;
+ dev->dev.release = fsi_device_release;
+
+ return dev;
+}
+
/* FSI slave support */
+static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
+ void *val, size_t size)
+{
+ return slave->master->read(slave->master, slave->link,
+ slave->id, addr, val, size);
+}
+
+static int fsi_slave_scan(struct fsi_slave *slave)
+{
+ uint32_t engine_addr;
+ uint32_t conf;
+ int rc, i;
+
+ /*
+ * scan engines
+ *
+ * We keep the peek mode and slave engines for the core; so start
+ * at the third slot in the configuration table. We also need to
+ * skip the chip ID entry at the start of the address space.
+ */
+ engine_addr = engine_page_size * 3;
+ for (i = 2; i < engine_page_size / sizeof(uint32_t); i++) {
+ uint8_t slots, version, type, crc;
+ struct fsi_device *dev;
+
+ rc = fsi_slave_read(slave, (i + 1) * sizeof(conf),
+ &conf, sizeof(conf));
+ if (rc) {
+ dev_warn(&slave->dev,
+ "error reading slave registers\n");
+ return -1;
+ }
+
+ crc = crc_fsi(0, conf >> FSI_SLAVE_CONF_CRC_SHIFT,
+ FSI_SLAVE_CONF_DATA_BITS);
+ if (crc != (conf & FSI_SLAVE_CONF_CRC_MASK)) {
+ dev_warn(&slave->dev,
+ "crc error in slave register at 0x%04x\n",
+ i);
+ return -1;
+ }
+
+ slots = (conf & FSI_SLAVE_CONF_SLOTS_MASK)
+ >> FSI_SLAVE_CONF_SLOTS_SHIFT;
+ version = (conf & FSI_SLAVE_CONF_VERSION_MASK)
+ >> FSI_SLAVE_CONF_VERSION_SHIFT;
+ type = (conf & FSI_SLAVE_CONF_TYPE_MASK)
+ >> FSI_SLAVE_CONF_TYPE_SHIFT;
+
+ /*
+ * Unused address areas are marked by a zero type value; this
+ * skips the defined address areas
+ */
+ if (type != 0) {
+
+ /* create device */
+ dev = fsi_create_device(slave);
+ if (!dev)
+ return -ENOMEM;
+
+ dev->slave = slave;
+ dev->engine_type = type;
+ dev->version = version;
+ dev->unit = i;
+ dev->addr = engine_addr;
+ dev->size = slots * engine_page_size;
+
+ dev_info(&slave->dev,
+ "engine[%i]: type %x, version %x, addr %x size %x\n",
+ dev->unit, dev->engine_type, version,
+ dev->addr, dev->size);
+
+ device_initialize(&dev->dev);
+ dev_set_name(&dev->dev, "%02x:%02x:%02x:%02x",
+ slave->master->idx, slave->link,
+ slave->id, i - 2);
+
+ rc = device_add(&dev->dev);
+ if (rc) {
+ dev_warn(&slave->dev, "add failed: %d\n", rc);
+ put_device(&dev->dev);
+ }
+ }
+
+ engine_addr += slots * engine_page_size;
+
+ if (!(conf & FSI_SLAVE_CONF_NEXT_MASK))
+ break;
+ }
+
+ return 0;
+}
+
static void fsi_slave_release(struct device *dev)
{
struct fsi_slave *slave = to_fsi_slave(dev);
@@ -91,7 +218,8 @@ static int fsi_slave_init(struct fsi_master *master,
return rc;
}
- return rc;
+ fsi_slave_scan(slave);
+ return 0;
}
/* FSI master support */
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index 273cbf6..efa55ba 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -21,6 +21,10 @@ struct fsi_device {
struct device dev;
u8 engine_type;
u8 version;
+ u8 unit;
+ struct fsi_slave *slave;
+ uint32_t addr;
+ uint32_t size;
};
struct fsi_device_id {
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 10/18] drivers/fsi: Add device read/write/peek functions
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 22:31 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
Cc: Chris Bostic
From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
This change introduces the fsi device API: simple read, write and peek
accessors for the devices' address spaces.
Includes contributions from Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
V2 - Clean up white space.
---
drivers/fsi/fsi-core.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsi.h | 6 ++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index f7ef993..3119aa1 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -35,6 +35,8 @@
#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
#define FSI_SLAVE_CONF_DATA_BITS 28
+#define FSI_PEEK_BASE 0x410
+
static const int engine_page_size = 0x400;
static DEFINE_IDA(master_ida);
@@ -48,8 +50,46 @@ struct fsi_slave {
#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
+static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
+ void *val, size_t size);
+static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
+ const void *val, size_t size);
+
/* FSI endpoint-device support */
+int fsi_device_read(struct fsi_device *dev, uint32_t addr, void *val,
+ size_t size)
+{
+ if (addr > dev->size)
+ return -EINVAL;
+
+ if (addr + size > dev->size)
+ return -EINVAL;
+
+ return fsi_slave_read(dev->slave, dev->addr + addr, val, size);
+}
+EXPORT_SYMBOL_GPL(fsi_device_read);
+
+int fsi_device_write(struct fsi_device *dev, uint32_t addr, const void *val,
+ size_t size)
+{
+ if (addr > dev->size)
+ return -EINVAL;
+
+ if (addr + size > dev->size)
+ return -EINVAL;
+
+ return fsi_slave_write(dev->slave, dev->addr + addr, val, size);
+}
+EXPORT_SYMBOL_GPL(fsi_device_write);
+
+int fsi_device_peek(struct fsi_device *dev, void *val)
+{
+ uint32_t addr = FSI_PEEK_BASE + ((dev->unit - 2) * sizeof(uint32_t));
+
+ return fsi_slave_read(dev->slave, addr, val, sizeof(uint32_t));
+}
+
static void fsi_device_release(struct device *_device)
{
struct fsi_device *device = to_fsi_dev(_device);
@@ -81,6 +121,13 @@ static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
slave->id, addr, val, size);
}
+static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
+ const void *val, size_t size)
+{
+ return slave->master->write(slave->master, slave->link,
+ slave->id, addr, val, size);
+}
+
static int fsi_slave_scan(struct fsi_slave *slave)
{
uint32_t engine_addr;
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index efa55ba..273945d 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -27,6 +27,12 @@ struct fsi_device {
uint32_t size;
};
+extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
+ void *val, size_t size);
+extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
+ const void *val, size_t size);
+extern int fsi_device_peek(struct fsi_device *dev, void *val);
+
struct fsi_device_id {
u8 engine_type;
u8 version;
--
1.8.2.2
--
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 related
* [PATCH v2 11/18] drivers/fsi: Set up links for slave communication
From: christopher.lee.bostic @ 2017-01-12 22:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Enable each link and send a break command in preparation
for scanning each link for slaves.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
drivers/fsi/fsi-core.c | 38 ++++++++++++++++++++++++++++++++++++--
drivers/fsi/fsi-master.h | 2 ++
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 3119aa1..b2c9274 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -271,14 +271,48 @@ static int fsi_slave_init(struct fsi_master *master,
/* FSI master support */
+static int fsi_master_link_enable(struct fsi_master *master, int link)
+{
+ if (master->link_enable)
+ return master->link_enable(master, link);
+
+ return 0;
+}
+
+/*
+ * Issue a break command on this link
+ */
+static int fsi_master_break(struct fsi_master *master, int link)
+{
+ if (master->send_break)
+ return master->send_break(master, link);
+
+ return 0;
+}
+
static int fsi_master_scan(struct fsi_master *master)
{
- int link, slave_id;
+ int link, slave_id, rc;
+
+ for (link = 0; link < master->n_links; link++) {
+ rc = fsi_master_link_enable(master, link);
+ if (rc) {
+ dev_dbg(master->dev,
+ "enable link:%d failed with:%d\n", link, rc);
+ continue;
+ }
+ rc = fsi_master_break(master, link);
+ if (rc) {
+ dev_dbg(master->dev,
+ "Break to link:%d failed with:%d\n", link, rc);
+ continue;
+ }
- for (link = 0; link < master->n_links; link++)
for (slave_id = 0; slave_id < FSI_N_SLAVES; slave_id++)
fsi_slave_init(master, link, slave_id);
+ }
+
return 0;
}
diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
index e75a810..94a0671 100644
--- a/drivers/fsi/fsi-master.h
+++ b/drivers/fsi/fsi-master.h
@@ -29,6 +29,8 @@ struct fsi_master {
int (*write)(struct fsi_master *, int link,
uint8_t slave, uint32_t addr,
const void *val, size_t size);
+ int (*send_break)(struct fsi_master *, int link);
+ int (*link_enable)(struct fsi_master *, int link);
};
extern int fsi_master_register(struct fsi_master *master);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 12/18] drivers/fsi: Set slave SMODE to init communication
From: christopher.lee.bostic @ 2017-01-12 22:33 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Set CFAM to appropriate ID so that the controlling master
can manage link memory ranges. Add slave engine register
definitions.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
drivers/fsi/fsi-core.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index b2c9274..af7965f 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -36,6 +36,7 @@
#define FSI_SLAVE_CONF_DATA_BITS 28
#define FSI_PEEK_BASE 0x410
+#define FSI_SLAVE_BASE 0x800
static const int engine_page_size = 0x400;
@@ -55,8 +56,26 @@ static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
const void *val, size_t size);
-/* FSI endpoint-device support */
+/*
+ * FSI slave engine control register offsets
+ */
+#define FSI_SMODE 0x0 /* R/W: Mode register */
+
+/*
+ * SMODE fields
+ */
+#define FSI_SMODE_WSC 0x80000000 /* Warm start done */
+#define FSI_SMODE_ECRC 0x20000000 /* Hw CRC check */
+#define FSI_SMODE_SID_SHIFT 24 /* ID shift */
+#define FSI_SMODE_SID_MASK 3 /* ID Mask */
+#define FSI_SMODE_ED_SHIFT 20 /* Echo delay shift */
+#define FSI_SMODE_ED_MASK 0xf /* Echo delay mask */
+#define FSI_SMODE_SD_SHIFT 16 /* Send delay shift */
+#define FSI_SMODE_SD_MASK 0xf /* Send delay mask */
+#define FSI_SMODE_LBCRR_SHIFT 8 /* Clk ratio shift */
+#define FSI_SMODE_LBCRR_MASK 0xf /* Clk ratio mask */
+/* FSI endpoint-device support */
int fsi_device_read(struct fsi_device *dev, uint32_t addr, void *val,
size_t size)
{
@@ -114,6 +133,30 @@ static struct fsi_device *fsi_create_device(struct fsi_slave *slave)
/* FSI slave support */
+/* Encode slave local bus echo delay */
+static inline uint32_t fsi_smode_echodly(int x)
+{
+ return (x & FSI_SMODE_ED_MASK) << FSI_SMODE_ED_SHIFT;
+}
+
+/* Encode slave local bus send delay */
+static inline uint32_t fsi_smode_senddly(int x)
+{
+ return (x & FSI_SMODE_SD_MASK) << FSI_SMODE_SD_SHIFT;
+}
+
+/* Encode slave local bus clock rate ratio */
+static inline uint32_t fsi_smode_lbcrr(int x)
+{
+ return (x & FSI_SMODE_LBCRR_MASK) << FSI_SMODE_LBCRR_SHIFT;
+}
+
+/* Encode slave ID */
+static inline uint32_t fsi_smode_sid(int x)
+{
+ return (x & FSI_SMODE_SID_MASK) << FSI_SMODE_SID_SHIFT;
+}
+
static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
void *val, size_t size)
{
@@ -221,6 +264,22 @@ static void fsi_slave_release(struct device *dev)
kfree(slave);
}
+static uint32_t set_smode_defaults(struct fsi_master *master)
+{
+ return FSI_SMODE_WSC | FSI_SMODE_ECRC
+ | fsi_smode_echodly(0xf) | fsi_smode_senddly(0xf)
+ | fsi_smode_lbcrr(1);
+}
+
+static int fsi_slave_set_smode(struct fsi_master *master, int link, int id)
+{
+ uint32_t smode = set_smode_defaults(master);
+
+ smode |= fsi_smode_sid(id);
+ return master->write(master, link, 3, FSI_SLAVE_BASE + FSI_SMODE,
+ &smode, sizeof(smode));
+}
+
static int fsi_slave_init(struct fsi_master *master,
int link, uint8_t slave_id)
{
@@ -229,6 +288,21 @@ static int fsi_slave_init(struct fsi_master *master,
int rc;
uint8_t crc;
+ /*
+ * todo: Due to CFAM hardware issues related to BREAK commands we're
+ * limited to only one CFAM per link. Once issues are resolved this
+ * restriction can be removed.
+ */
+ if (slave_id > 0)
+ return 0;
+
+ rc = fsi_slave_set_smode(master, link, slave_id);
+ if (rc) {
+ dev_warn(master->dev, "can't set smode on slave:%02x:%02x %d\n",
+ link, slave_id, rc);
+ return -ENODEV;
+ }
+
rc = master->read(master, link, slave_id, 0, &chip_id, sizeof(chip_id));
if (rc) {
dev_warn(master->dev, "can't read slave %02x:%02x: %d\n",
@@ -293,6 +367,7 @@ static int fsi_master_break(struct fsi_master *master, int link)
static int fsi_master_scan(struct fsi_master *master)
{
int link, slave_id, rc;
+ uint32_t smode;
for (link = 0; link < master->n_links; link++) {
rc = fsi_master_link_enable(master, link);
@@ -308,6 +383,19 @@ static int fsi_master_scan(struct fsi_master *master)
continue;
}
+ /*
+ * Verify can read slave at default ID location. If fails
+ * there must be nothing on other end of link
+ */
+ rc = master->read(master, link, 3, FSI_SLAVE_BASE + FSI_SMODE,
+ &smode, sizeof(smode));
+ if (rc) {
+ dev_dbg(master->dev,
+ "Read link:%d smode default id failed:%d\n",
+ link, rc);
+ continue;
+ }
+
for (slave_id = 0; slave_id < FSI_N_SLAVES; slave_id++)
fsi_slave_init(master, link, slave_id);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 13/18] drivers/fsi: Remove all scanned devices during master unregister
From: christopher.lee.bostic @ 2017-01-12 22:34 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Master will remove all previously scanned devices during an
unregister operation. This will be necessary should any master
attempt to register more than once.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Remove list heads and explicit master device list management
int the fsi master and fsi slave structs. Instead utilize the
device_for_each_child method already available.
---
drivers/fsi/fsi-core.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index af7965f..28b82d1 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -428,12 +428,26 @@ int fsi_master_register(struct fsi_master *master)
}
EXPORT_SYMBOL_GPL(fsi_master_register);
+static int fsi_slave_device_remove(struct device *dev, void *data)
+{
+ put_device(dev);
+ return 0;
+}
+
+static int fsi_master_slave_remove(struct device *dev, void *data)
+{
+ device_for_each_child(dev, NULL, fsi_slave_device_remove);
+ device_unregister(dev);
+ return 0;
+}
+
void fsi_master_unregister(struct fsi_master *master)
{
if (!master || !master->dev)
return;
ida_simple_remove(&master_ida, master->idx);
+ device_for_each_child(master->dev, NULL, fsi_master_slave_remove);
put_device(master->dev);
}
EXPORT_SYMBOL_GPL(fsi_master_unregister);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 14/18] drivers/fsi: Add FSI bus documentation
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 22:34 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
Cc: Chris Bostic
From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Add details on the basic functions of the FSI serial bus.
Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt
new file mode 100644
index 0000000..7fa2394
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi.txt
@@ -0,0 +1,54 @@
+FSI: Flexible Support processor Interface
+
+FSI is a two line serial bus capable of running at speeds up to 166 MHz.
+The lines consist of a clock responsible for synchronizing the target device
+(slave) with the master which is responsible for all transactions on the bus.
+The master owns the clock line and is the only side allowed to change its
+state. The second line, SDA, is a data line that conveys information to/from
+the slave who samples based on the clock line. The data line is
+bi-directional.
+
+The master initiates communication by sending a command to the slave and
+depending on the type of command will allow the slave to control the bus
+to return requested data. All commands are CRC protected. The slave upon
+receipt of a command will determine if the CRC is correct and discard
+the data if noise has corrupted the line. In the same manner the master
+will verify the CRC received from the slave.
+
+Types of commands:
+Read 32 bit: Read a 32 bit word from a specified address on the slave.
+Read 16 bit: Read a 16 bit 'half word' from a specified address on the slave.
+read 8 bit: Read a byte from a specified address on the slave.
+Write 32,16,8 bit: Write to a specified address on the slave with the provided
+ data.
+BREAK: Initialize the slave's logic to receive commands.
+TERM: Terminate the slave's error lockout to resume communications
+ after an error on the bus is detected.
+D-POLL: Poll the slave to determine when it is no longer buy processing
+ a previous command.
+I-POLL: Interrupt signal check. Master queries slave to see if any
+ interrupts are asserting.
+
+High fanout capability:
+FSI buses can be chained together in 'hub' configurations to expand the
+available communications channels and thus allow connetion to more slaves.
+
+
+Typical implementation
+
+ FSI master ----- slave with local FSI master (hub) ------- downstream slave
+
+
+Each two line combination of a clock and data line is collectively referred
+to as a 'FSI link'. Depending on hardware the primary FSI master may support
+up to 64 links. Hub FSI masters can support at most 8 links. Total number
+of supported slaves can grow exponentially depending on how many hubs are
+placed in the path. Presently only two hubs in the chain are allowed but
+in the future this may be expanded.
+
+The slave hardware logic responsible for decoding FSI master commands is
+contained in a CFAM (Common Field replaceable unit Access Macro). Up to
+4 slaves or CFAMs can be connected on each FSI link. CFAMs in addition
+to the slave logic (or engine) can contain other functions that allow access
+via FSI. Common additional functionality includes I2C masters, GPIO
+controllers, UARTs, etc...
--
1.8.2.2
--
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 related
* [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master
From: christopher.lee.bostic @ 2017-01-12 22:35 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Define the device tree bindings for the GPIO master type.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
V2 - Break out this documentation update from the code implementing
The GPIO master function.
- Move the documentation to an earlier patch than the code
implementing the function.
- Document all 'compatible' strings used in the series.
- Write binding document in terms of hardware, not software.
- Elaborate on what a GPIO based FSI master is versus a non
GPIO based master.
- Give a more detailed description of what each pin in the GPIO
FSI master is to be used for.
- Re-order compatible strings in example so that most specific
comes first.
- Indicate the proper order each pin should be initialized.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example list items individually.
---
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
new file mode 100644
index 0000000..5d589bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
@@ -0,0 +1,71 @@
+Device-tree bindings for FSI master implemented with GPIO
+---------------------------------------------------------
+
+Typically a FSI master is defined in hardware with output control
+lines designated for Enable, Data, Clock, etc.. In the case of
+a 'GPIO FSI master', however, it may be the case that there is no
+such master defined in hardware and must be implemented in standard
+GPIO to interact with its slaves. In this 'virtual' FSI master
+case the GPIO pins representing clk and data are directly
+connected to the slaves.
+
+The GPIO FSI master node
+-------------------------
+This node describes a FSI master implmented with GPIO.
+Required property:
+ compatible = "ibm,fsi-master-gpio"
+
+The standard FSI master node
+----------------------------
+This node describes a FSI master implmemented fully in hardware
+with dedicated input/output pins required for its function (i.e.
+not using generic GPIO pins).
+Required property:
+ compatible = "ibm,fsi-master"
+
+
+GPIO FSI master property/pin descriptions
+------------------------------------------
+clk - The master controlled clock line that indicates to the
+ slave when to read in or send out new data - required.
+data - The serial data line containing information to be sent or
+ received by the master. This line is bi-directional. During
+ command phase the master controls the line and when a response
+ is required the slave takes control - required.
+enable - Controls power state of data line - optional.
+trans - Voltage translator control. In some applications the data line
+ must have its signal levels altered by a translator. If this is
+ necessary then control of signal direction is managed via this
+ line - optional.
+mux - Multiplexor control. This activates/deactivates the data line
+ in cases where it is one of many possible selections via mux -
+ optional.
+
+Required properties:
+ - compatible = "ibm,fsi-master-gpio";
+ - clk-gpios;
+ - data-gpios;
+
+Optional properties:
+ - enable-gpios;
+ - trans-gpios;
+ - mux-gpios;
+
+Order of property activation:
+1. clk
+2. data
+3. trans
+4. enable
+5. mux
+
+
+Example:
+
+fsi-master {
+ compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
+ clk-gpios = <&gpio 0>, <&gpio 6>;
+ data-gpios = <&gpio 1>, <&gpio 7>;
+ enable-gpios = <&gpio 2>, <&gpio 8>;
+ trans-gpios = <&gpio 3>, <&gpio 9>;
+ mux-gpios = <&gpio 4>, <&gpio 10>;
+}
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 16/18] drivers/fsi: Document FSI master sysfs files in ABI
From: christopher.lee.bostic @ 2017-01-12 22:36 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Add info for sysfs scan file in Documentaiton ABI/testing
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-fsi | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi
new file mode 100644
index 0000000..dfcbc1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-fsi
@@ -0,0 +1,6 @@
+What: /sys/bus/platform/devices/fsi-master/scan
+KernelVersion: 4.9
+Contact: cbostic@us.ibm.com
+Description:
+ Initiates a FSI master scan for all connected
+ slave devices on its links.
--
1.8.2.2
^ permalink raw reply related
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