* 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
* [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 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
* 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 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: 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] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-12 20:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdUz6nb-STMQK39hDqwHRt4R5t+Lndj150Lkg7prN=HQZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> This is strange. There are two SDHI channels, but the STBCR12
> documentation (all versions up to rev. 3.00) says the register has MSTP
> bits for four SD host interfaces?
>
> Can you please enlighten me? Thanks!
Ya, I saw that. There are 2 bits per SDHI channel. I did check and just
enabling the one works fine.
Honestly, I'm not sure why there are two clock enables.
I'll go back and ask the design team if they can tell me why there are 2.
As I said, I just re-tested and it works fine, but you can hold off on the
patch if you want until I come up with a real explanation.
Chris
^ permalink raw reply
* Re: [PATCH v2] i2c: do not enable fall back to Host Notify by default
From: Dmitry Torokhov @ 2017-01-12 20:33 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rob Herring, Benjamin Tissoires, Pali Rohár,
Michał Kępień, Jean Delvare, Takashi Iwai,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20170112184101.slxulrvreq7zl2pc@ninjato>
On Thu, Jan 12, 2017 at 07:41:01PM +0100, Wolfram Sang wrote:
> On Wed, Jan 04, 2017 at 08:57:22PM -0800, Dmitry Torokhov wrote:
> > Falling back unconditionally to HostNotify as primary client's interrupt
> > breaks some drivers which alter their functionality depending on whether
> > interrupt is present or not, so let's introduce a board flag telling I2C
> > core explicitly if we want wired interrupt or HostNotify-based one:
> > I2C_CLIENT_HOST_NOTIFY.
> >
> > For DT-based systems we introduce "host-notify" property that we convert
> > to I2C_CLIENT_HOST_NOTIFY board flag.
> >
> > Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Applied to for-current, thanks!
>
> How do we handle driver fixes? Shall I take them via I2C to have the
> dependency clear? Or can they go seperately?
The drivers that need this will go [hopefully] into next so they should
be OK to go through my tree.
--
Dmitry
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-12 20:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel-u79uwXL29TY76Z2rM5mHXA
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* Pinconf
* GPIOs
* MicroSD card reader
* UART on input port 1
* Buttons
* LEDs
* Poweroff/reset
* Flash memory
* EEPROM
* USB host port
* USB peripheral port
What is not working/to be added later:
* Speaker - have patch submitted to get pwm-beeper working - maybe someday
it will have a real sound driver that uses PRU
* A/DC chip - have driver submitted and accepted - waiting for ack on
device tree bindings
* Display - waiting for "simple DRM" to be mainlined
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver as
well as PRU UART and PRU I2C drivers
* Battery indication - needs new power supply driver
Note on flash partitions:
These partitions are based on the official EV3 firmware from LEGO. It is
expected that most users of the mainline kernel on EV3 will be booting from
an SD card while retaining the official firmware in the flash memory.
Furthermore, the official firmware uses an ancient U-Boot (2009) that has
no device tree support. So, it makes sense to have this partition table in
the EV3 device tree file. In the unlikely case that anyone does create their
own firmware image with different partitioning, they can use a modern
U-Boot in their own firmware image that modifies the device tree with the
custom partitions.
Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
v3 changes:
* required defconfig patches have been picked up in linux-davinci tree, so this
is the only patch left in the series
* Added aliases node for consistent naming of serial ports
* Added memory node
* Removed nodes that are not finalized yet
* Renamed button labels to match EV3 users manual
v2 changes:
* Dropped defconfig patches that have already been pick up
* Added some new defconfig patches
* Updated device tree file based on feedback and new available bindings
* Renamed file to include da850- prefix
* Changed button labels
* Fixed LED names
* Added beeper device for sound
* Added regulators for USB and A/DC
* Removed unused pinmux nodes
* Added pinconf for buttons
* Enabled pwms
* Used preferred bindings for flash partitions
* Added A/DC spi device
* Enabled USB
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++++++++++++++++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b7..1a19e7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -130,7 +130,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ da850-lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
new file mode 100644
index 0000000..7aaf902
--- /dev/null
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -0,0 +1,313 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ aliases {
+ serial1 = &serial1;
+ };
+
+ memory@c0000000 {
+ device_type = "memory";
+ reg = <0xc0000000 0x04000000>;
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 Brick Buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>, <&button_bias>;
+
+ center {
+ label = "Center";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ left {
+ label = "Left";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+
+ back {
+ label = "Back";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+
+ right {
+ label = "Right";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+
+ down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+
+ up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_green {
+ label = "led0:green:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_red {
+ label = "led1:red:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ left_red {
+ label = "led0:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_green {
+ label = "led1:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * This is a 5V current limiting regulator that is shared by USB,
+ * the sensor (input) ports, the motor (output) ports and the A/DC.
+ */
+ vcc5v: regulator1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v_pins>;
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio 101 0>;
+ over-current-gpios = <&gpio 99 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+
+ vcc5v_pins: pinmux_vcc5v {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+&pinconf {
+ status = "okay";
+
+ /* Buttons have external pulldown resistors */
+ button_bias: button-bias-groups {
+ disable {
+ groups = "cp5", "cp24", "cp25", "cp28";
+ bias-disable;
+ };
+ };
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom@50 {
+ compatible = "at24,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+
+ flash@0 {
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ /* Partitions are based on the official firmware from LEGO */
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition@40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition@50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition@250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition@cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+ };
+};
+
+&gpio {
+ status = "okay";
+};
+
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+ vbus-supply = <&vcc5v>;
+};
--
2.7.4
--
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: r7s72100: fix sdhi clock define
From: Geert Uytterhoeven @ 2017-01-12 19:57 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170112181149.29035-1-chris.brandt@renesas.com>
Hi Chris,
On Thu, Jan 12, 2017 at 7:11 PM, Chris Brandt <chris.brandt@renesas.com> wrote:
> Now that all the clocks in the boot loader are disabled before booting
> the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo
> that was missed during original testing.
>
> Fixes: 7c8522b7047c ("ARM: dts: r7s72100: add sdhi clock to device tree")
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> ---
> include/dt-bindings/clock/r7s72100-clock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
> index 29e01ed..318ab14 100644
> --- a/include/dt-bindings/clock/r7s72100-clock.h
> +++ b/include/dt-bindings/clock/r7s72100-clock.h
> @@ -46,6 +46,6 @@
>
> /* MSTP12 */
> #define R7S72100_CLK_SDHI0 3
> -#define R7S72100_CLK_SDHI1 2
> +#define R7S72100_CLK_SDHI1 1
This is strange. There are two SDHI channels, but the STBCR12 documentation
(all versions up to rev. 3.00) says the register has MSTP bits for four SD
host interfaces?
Can you please enlighten me? Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Tim Harvey @ 2017-01-12 19:37 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
Russell King - ARM Linux, mchehab, Hans Verkuil, Nick Dyer,
markus.heiser, Philipp Zabel, laurent.pinchart+renesas, bparrot,
geert, Arnd Bergmann, Sudip Mukherjee, minghsiu.tsai, Tiffany Lin,
Jean-Christophe TROTIN, Simon Horman
In-Reply-To: <1483755102-24785-11-git-send-email-steve_longerbeam@mentor.com>
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Add pinctrl groups for both GPT input capture channels.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 967c3b8..495709f 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -457,6 +457,18 @@
> >;
> };
>
> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
> + >;
> + };
> +
> pinctrl_spdif: spdifgrp {
> fsl,pins = <
> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
> --
Steve,
These are not used anywhere.
Tim
^ permalink raw reply
* Re: [PATCH v3 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Wolfram Sang @ 2017-01-12 19:15 UTC (permalink / raw)
To: Phil Reid
Cc: peda-koto5C5qi+TLoDKTGw+V6w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483952576-5308-4-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On Mon, Jan 09, 2017 at 05:02:54PM +0800, Phil Reid wrote:
> Various muxes can aggregate multiple interrupts from each i2c bus.
> All of the muxes with interrupt support combine the active low irq lines
> using an internal 'and' function and generate a combined active low
> output. The muxes do provide the ability to read a control register to
> determine which irq is active. By making the mux an irq controller isr
> latency can potentially be reduced by reading the status register and
> then only calling the registered isr on that bus segment.
>
> As there is no irq masking on the mux irq are disabled until irq_unmask is
> called at least once.
>
> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
Is the ack from Peda here forgotten or still missing?
@peda: Once you are happy, do you want to take these patches via your
shiny new mux-tree or do you prefer if I pick them?
Regards,
Wolfram
--
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 3/3] ARM: dts: rskrza1: add ostm DT support
From: Chris Brandt @ 2017-01-12 19:01 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170112190108.2856-1-chris.brandt@renesas.com>
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 ++++
arch/arm/boot/dts/r7s72100.dtsi | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index dd44181..e7b6afa 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -61,6 +61,10 @@
status = "okay";
};
+&ostm {
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 247bbe0..974c084 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -513,7 +513,8 @@
interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING
GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
- clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks R7S72100_CLK_OSTM1>;
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>,
+ <&mstp5_clks R7S72100_CLK_OSTM1>;
status = "disabled";
};
};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r7s72100: add ostm to device tree
From: Chris Brandt @ 2017-01-12 19:01 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170112190108.2856-1-chris.brandt@renesas.com>
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index d5946df..247bbe0 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -505,4 +505,15 @@
cap-sdio-irq;
status = "disabled";
};
+
+ ostm: ostm@fcfec000 {
+ compatible = "renesas,ostm-r7s72100", "renesas,ostm";
+ reg = <0xfcfec000 0x30>,
+ <0xfcfec400 0x30>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks R7S72100_CLK_OSTM1>;
+ status = "disabled";
+ };
};
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: r7s72100: add ostm clock to device tree
From: Chris Brandt @ 2017-01-12 19:01 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170112190108.2856-1-chris.brandt@renesas.com>
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100.dtsi | 9 +++++++++
include/dt-bindings/clock/r7s72100-clock.h | 4 ++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 3dd427d..d5946df 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -108,6 +108,15 @@
clock-output-names = "scif0", "scif1", "scif2", "scif3", "scif4", "scif5", "scif6", "scif7";
};
+ mstp5_clks: mstp5_clks@fcfe0428 {
+ #clock-cells = <1>;
+ compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
+ reg = <0xfcfe0428 4>;
+ clocks = <&p0_clk>, <&p0_clk>;
+ clock-indices = <R7S72100_CLK_OSTM0 R7S72100_CLK_OSTM1>;
+ clock-output-names = "ostm0", "ostm1";
+ };
+
mstp7_clks: mstp7_clks@fcfe0430 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed..ce09915 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -25,6 +25,10 @@
#define R7S72100_CLK_SCIF6 1
#define R7S72100_CLK_SCIF7 0
+/* MSTP5 */
+#define R7S72100_CLK_OSTM0 1
+#define R7S72100_CLK_OSTM1 0
+
/* MSTP7 */
#define R7S72100_CLK_ETHER 4
--
2.10.1
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: add ostm support for r7s72100
From: Chris Brandt @ 2017-01-12 19:01 UTC (permalink / raw)
To: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
This patch set enables the use of the newly created driver
renesas-ostm.c for the r7s72100 SoC.
This patch set depends on the acceptance of:
[PATCH 1/2] dt-bindings: document renesas-ostm timer
[PATCH 2/2] clocksource: Add renesas-ostm timer driver
Chris Brandt (3):
ARM: dts: r7s72100: add ostm clock to device tree
ARM: dts: r7s72100: add ostm to device tree
ARM: dts: rskrza1: add ostm DT support
arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 ++++
arch/arm/boot/dts/r7s72100.dtsi | 21 +++++++++++++++++++++
include/dt-bindings/clock/r7s72100-clock.h | 4 ++++
3 files changed, 29 insertions(+)
--
2.10.1
^ permalink raw reply
* [PATCH 2/2] clocksource: Add renesas-ostm timer driver
From: Chris Brandt @ 2017-01-12 18:59 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Simon Horman, Magnus Damm,
Russell King, Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170112185952.2780-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
This patch adds a OSTM driver for the Renesas architecture.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/mach-shmobile/Kconfig | 1 +
drivers/clocksource/Kconfig | 12 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/renesas-ostm.c | 389 +++++++++++++++++++++++++++++++++++++
4 files changed, 403 insertions(+)
create mode 100644 drivers/clocksource/renesas-ostm.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2bb4b09..b928634 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
+ select SYS_SUPPORTS_RENESAS_OSTM
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4866f7a..95c8d56 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -431,6 +431,9 @@ config MTK_TIMER
config SYS_SUPPORTS_SH_MTU2
bool
+config SYS_SUPPORTS_RENESAS_OSTM
+ bool
+
config SYS_SUPPORTS_SH_TMU
bool
@@ -467,6 +470,15 @@ config SH_TIMER_MTU2
Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas.
This hardware comes with 16 bit-timer registers.
+config RENESAS_OSTM
+ bool "Renesas OSTM timer driver" if COMPILE_TEST
+ depends on GENERIC_CLOCKEVENTS
+ select CLKSRC_MMIO
+ default SYS_SUPPORTS_RENESAS_OSTM
+ help
+ This enables the build of the OSTM timer driver.
+ It creates a clock source and clock event device.
+
config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index a14111e..bbd163b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC) += cs5535-clockevt.o
obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
obj-$(CONFIG_SH_TIMER_MTU2) += sh_mtu2.o
+obj-$(CONFIG_RENESAS_OSTM) += renesas-ostm.o
obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
obj-$(CONFIG_CLKBLD_I8253) += i8253.o
diff --git a/drivers/clocksource/renesas-ostm.c b/drivers/clocksource/renesas-ostm.c
new file mode 100644
index 0000000..3b417b9
--- /dev/null
+++ b/drivers/clocksource/renesas-ostm.c
@@ -0,0 +1,389 @@
+/*
+ * Renesas Timer Support - OSTM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License
+ *
+ * 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/platform_device.h>
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/sched_clock.h>
+
+/*
+ * The OSTM comes with 2 independent channels.
+ * We will use the first channel (OSTM0) as a free running clocksource and the
+ * second channel (OSTM1) as a interrupt driven clock event.
+ *
+ * Additionally we will use the clocksource channel (OTSM0) for the system
+ * schedule timer sched_clock().
+ */
+
+struct ostm_channel {
+ int irq;
+ struct clk *clk;
+ unsigned long rate;
+ void __iomem *base;
+ unsigned long ticks_per_jiffy;
+ struct clock_event_device ced;
+ struct clocksource cs;
+};
+
+struct ostm_device {
+ struct platform_device *pdev;
+ struct ostm_channel clksrc; /* clock source ostm0 */
+ struct ostm_channel clkevt; /* clock event ostm1 */
+};
+
+static void __iomem *system_clock; /* For sched_clock() */
+
+/* OSTM REGISTERS */
+#define OSTM_CMP 0x000 /* RW,32 */
+#define OSTM_CNT 0x004 /* R,32 */
+#define OSTM_TE 0x010 /* R,8 */
+#define OSTM_TS 0x014 /* W,8 */
+#define OSTM_TT 0x018 /* W,8 */
+#define OSTM_CTL 0x020 /* RW,8 */
+
+#define TE 0x01
+#define TS 0x01
+#define TT 0x01
+#define CTL_PERIODIC 0x00
+#define CTL_ONESHOT 0x02
+#define CTL_FREERUN 0x02
+
+static struct ostm_channel *ced_to_ostm_ch(struct clock_event_device *ced)
+{
+ return container_of(ced, struct ostm_channel, ced);
+}
+
+static int __init ostm_init_clksrc(struct ostm_device *ostm)
+{
+ struct ostm_channel *cs = &ostm->clksrc;
+ struct resource *res;
+ int ret = -ENXIO;
+
+ res = platform_get_resource(ostm->pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&ostm->pdev->dev, "failed to get I/O memory\n");
+ goto err;
+ }
+ cs->base = ioremap_nocache(res->start, resource_size(res));
+ if (!cs->base) {
+ dev_err(&ostm->pdev->dev, "failed to remap I/O memory\n");
+ goto err;
+ }
+
+ /* irq not used (clock sources don't use interrupts) */
+ cs->irq = platform_get_irq(ostm->pdev, 0);
+ if (cs->irq < 0) {
+ dev_err(&ostm->pdev->dev, "failed to get irq\n");
+ goto err_iounmap;
+ }
+
+ cs->clk = of_clk_get(ostm->pdev->dev.of_node, 0);
+ if (IS_ERR(cs->clk)) {
+ dev_err(&ostm->pdev->dev, "failed to get clock\n");
+ goto err_iounmap;
+ }
+
+ ret = clk_prepare_enable(cs->clk);
+ if (ret) {
+ dev_err(&ostm->pdev->dev, "failed to enable clock\n");
+ goto err_iounmap;
+ }
+ cs->rate = clk_get_rate(cs->clk);
+
+ /* stop counter */
+ iowrite8(TT, cs->base + OSTM_TT);
+ while (ioread8(cs->base + OSTM_TE) & TE)
+ ;
+
+ /* setup as freerun */
+ iowrite32(0, cs->base + OSTM_CMP);
+ iowrite8(CTL_FREERUN, cs->base + OSTM_CTL);
+ iowrite8(TS, cs->base + OSTM_TS);
+
+ /* register */
+ clocksource_mmio_init(cs->base + OSTM_CNT,
+ "ostm", cs->rate,
+ 300, 32, clocksource_mmio_readl_up);
+
+ return 0;
+
+err_iounmap:
+ iounmap(cs->base);
+err:
+ return ret;
+}
+
+static u64 notrace ostm_read_sched_clock(void)
+{
+ return ioread32(system_clock);
+}
+
+/*
+ * Setup sched_clock using clocksource device (uses ostm.0)
+ */
+static int __init ostm_init_sched_clock(struct ostm_channel *cs)
+{
+ unsigned long flags;
+
+ system_clock = cs->base + OSTM_CNT; /* ostm0 */
+ local_irq_save(flags);
+ local_irq_disable();
+ sched_clock_register(ostm_read_sched_clock, 32, cs->rate);
+ local_irq_restore(flags);
+ return 0;
+}
+
+static void ostm_clkevt_timer_stop(struct ostm_channel *ch)
+{
+ if (ioread8(ch->base + OSTM_TE) & TE) {
+ iowrite8(TT, ch->base + OSTM_TT);
+ while (ioread8(ch->base + OSTM_TE) & TE)
+ ;
+ }
+}
+
+static int ostm_clock_event_next(unsigned long delta,
+ struct clock_event_device *ced)
+{
+ struct ostm_channel *ch = ced_to_ostm_ch(ced);
+
+ WARN_ON(!clockevent_state_oneshot(ced));
+
+ ostm_clkevt_timer_stop(ch);
+
+ iowrite32(delta, ch->base + OSTM_CMP);
+ iowrite8(CTL_ONESHOT, ch->base + OSTM_CTL);
+ iowrite8(TS, ch->base + OSTM_TS);
+
+ return 0;
+}
+
+static int ostm_shutdown(struct clock_event_device *ced)
+{
+ struct ostm_channel *ch = ced_to_ostm_ch(ced);
+
+ ostm_clkevt_timer_stop(ch);
+ return 0;
+}
+static int ostm_set_periodic(struct clock_event_device *ced)
+{
+ struct ostm_channel *ch = ced_to_ostm_ch(ced);
+
+ if (clockevent_state_oneshot(ced) || clockevent_state_periodic(ced))
+ ostm_clkevt_timer_stop(ch);
+
+ iowrite32(ch->ticks_per_jiffy - 1, ch->base + OSTM_CMP);
+ iowrite8(CTL_PERIODIC, ch->base + OSTM_CTL);
+ iowrite8(TS, ch->base + OSTM_TS);
+
+ return 0;
+}
+
+static int ostm_set_oneshot(struct clock_event_device *ced)
+{
+ struct ostm_channel *ch = ced_to_ostm_ch(ced);
+
+ ostm_clkevt_timer_stop(ch);
+
+ return 0;
+}
+
+static irqreturn_t ostm_timer_interrupt(int irq, void *dev_id)
+{
+ struct ostm_channel *ch = dev_id;
+
+ if (clockevent_state_oneshot(&ch->ced))
+ ostm_clkevt_timer_stop(ch);
+
+ /* notify clockevent layer */
+ if (ch->ced.event_handler)
+ ch->ced.event_handler(&ch->ced);
+
+ return IRQ_HANDLED;
+}
+
+static int __init ostm_init_clkevt(struct ostm_device *ostm)
+{
+ struct ostm_channel *ce = &ostm->clkevt;
+ struct resource *res;
+ struct clock_event_device *ced;
+ int ret = -ENXIO;
+
+ res = platform_get_resource(ostm->pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ dev_err(&ostm->pdev->dev, "failed to get I/O memory\n");
+ goto err;
+ }
+
+ ce->base = ioremap_nocache(res->start, resource_size(res));
+ if (!ce->base) {
+ dev_err(&ostm->pdev->dev, "failed to remap I/O memory\n");
+ goto err;
+ }
+
+ ce->irq = platform_get_irq(ostm->pdev, 1);
+ if (ce->irq < 0) {
+ dev_err(&ostm->pdev->dev, "failed to get irq\n");
+ goto err_iounmap;
+ }
+
+ ce->clk = of_clk_get(ostm->pdev->dev.of_node, 1);
+ if (IS_ERR(ce->clk)) {
+ PTR_ERR(ce->clk);
+ dev_err(&ostm->pdev->dev, "failed to get clock\n");
+ goto err_iounmap;
+ }
+ ret = clk_prepare_enable(ce->clk);
+ if (ret) {
+ dev_err(&ostm->pdev->dev, "failed to enable clock\n");
+ goto err_iounmap;
+ }
+ ce->rate = clk_get_rate(ce->clk);
+
+ ce->ticks_per_jiffy = (ce->rate + HZ / 2) / HZ;
+
+ ret = request_irq(ce->irq, ostm_timer_interrupt,
+ IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
+ "ostm.1", ce);
+
+
+ if (ret) {
+ dev_err(&ostm->pdev->dev, "failed to request irq\n");
+ goto err_iounmap;
+ }
+
+ ced = &ce->ced;
+ ced->name = "ostm";
+ ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC;
+ ced->set_state_shutdown = ostm_shutdown;
+ ced->set_state_periodic = ostm_set_periodic;
+ ced->set_state_oneshot = ostm_set_oneshot;
+ ced->set_next_event = ostm_clock_event_next;
+ ced->shift = 32;
+ ced->rating = 300;
+ ced->cpumask = cpumask_of(0);
+ clockevents_config_and_register(ced, ce->rate, 0xf, 0xffffffff);
+
+ ret = 0;
+ return ret;
+
+err_iounmap:
+ iounmap(ce->base);
+err:
+ return ret;
+}
+
+static int __init ostm_timer_init(struct ostm_device *ostm)
+{
+ int ret = 0;
+
+ /* ostm0 will be clock source */
+ ret = ostm_init_clksrc(ostm);
+ if (ret)
+ goto err;
+
+ /* use ostm0 as system scheduling clock */
+ ret = ostm_init_sched_clock(&ostm->clksrc);
+ if (ret)
+ goto err;
+
+ /* ostm1 will be clock event */
+ ret = ostm_init_clkevt(ostm);
+err:
+ return ret;
+}
+
+static int __init ostm_probe(struct platform_device *pdev)
+{
+ struct ostm_device *ostm;
+ int ret = 0;
+
+ if (!is_early_platform_device(pdev)) {
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ }
+
+ ostm = platform_get_drvdata(pdev);
+ if (ostm) {
+ dev_info(&pdev->dev, "kept as earlytimer\n");
+ goto out;
+ }
+
+ ostm = kzalloc(sizeof(*ostm), GFP_KERNEL);
+ if (!ostm) {
+ dev_info(&pdev->dev, "failed to allocate memory\n");
+ return -ENOMEM;
+ }
+
+ ostm->pdev = pdev;
+ platform_set_drvdata(ostm->pdev, ostm);
+
+ ret = ostm_timer_init(ostm);
+ if (ret) {
+ kfree(ostm);
+ platform_set_drvdata(pdev, NULL);
+ pm_runtime_idle(&pdev->dev);
+ return ret;
+ }
+
+ if (is_early_platform_device(pdev))
+ return ret;
+
+out:
+ pm_runtime_irq_safe(&pdev->dev);
+
+ return ret;
+}
+
+static int ostm_remove(struct platform_device *pdev)
+{
+ return -EBUSY; /* cannot unregister clockevent */
+}
+
+static const struct of_device_id ostm_of_table[] __maybe_unused = {
+ { .compatible = "renesas,ostm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ostm_of_table);
+
+static struct platform_driver ostm_timer = {
+ .probe = ostm_probe,
+ .remove = ostm_remove,
+ .driver = {
+ .name = "ostm",
+ .of_match_table = of_match_ptr(ostm_of_table),
+ },
+};
+
+static int __init ostm_init(void)
+{
+ return platform_driver_register(&ostm_timer);
+}
+
+static void __exit ostm_exit(void)
+{
+ platform_driver_unregister(&ostm_timer);
+}
+
+early_platform_init("earlytimer", &ostm_timer);
+subsys_initcall(ostm_init);
+module_exit(ostm_exit);
+
+MODULE_AUTHOR("Chris Brandt");
+MODULE_DESCRIPTION("Renesas OSTM Timer Driver");
+MODULE_LICENSE("GPL v2");
--
2.10.1
--
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 1/2] dt-bindings: document renesas-ostm timer
From: Chris Brandt @ 2017-01-12 18:59 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Simon Horman, Magnus Damm,
Russell King, Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170112185952.2780-1-chris.brandt@renesas.com>
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
.../devicetree/bindings/timer/renesas,ostm.txt | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
new file mode 100644
index 0000000..46e1f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
@@ -0,0 +1,36 @@
+* Renesas OS Timer (OSTM)
+
+The OSTM comes with 2 independent channels.
+We will use the first channel (OSTM0) as a free running clocksource and the
+second channel (OSTM1) as a interrupt driven clock event.
+
+Additionally we will use the clocksource channel (OTSM0) for the system
+schedule timer sched_clock().
+
+Required Properties:
+
+ - compatible: must be one or more of the following:
+ - "renesas,ostm-r7s72100" for the r7s72100 OSTM
+ - "renesas,ostm" for any OSTM
+ This is a fallback for the above renesas,ostm-* entries
+
+ - reg: base address and length of the registers block for each timer channel.
+ There should be 2 sets of addresses, one for each channel.
+
+ - interrupts: interrupt specifiers for the timers. There should be 2
+ interupts, one for each channel.
+
+ - clocks: a list of phandle + clock-specifier pairs, one for each entry
+ channel. There should be 2 sets, one for each channel.
+
+Example: R7S72100 (RZ/A1H) OSTM node
+
+ ostm: ostm@fcfec000 {
+ compatible = "renesas,ostm-r7s72100", "renesas,ostm";
+ reg = <0xfcfec000 0x30>,
+ <0xfcfec400 0x30>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks R7S72100_CLK_OSTM1>;
+ };
--
2.10.1
^ permalink raw reply related
* [PATCH 0/2] clocksource: Add renesas-ostm timer driver
From: Chris Brandt @ 2017-01-12 18:59 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Simon Horman, Magnus Damm,
Russell King, Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
This patch set adds a new clocksource driver that uses the OS Timer
(OSTM) that exists in the R7S72100 (RZ/A1) SoC.
The operation of the driver was tested with a simple user application
that does multiple calls to nanosleep() and gettimeofday().
The purpose of adding this driver is to get better time keeping
accuracy over the default MTU2 clocksource timer.
Chris Brandt (2):
dt-bindings: document renesas-ostm timer
clocksource: Add renesas-ostm timer driver
.../devicetree/bindings/timer/renesas,ostm.txt | 36 ++
arch/arm/mach-shmobile/Kconfig | 1 +
drivers/clocksource/Kconfig | 12 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/renesas-ostm.c | 389 +++++++++++++++++++++
5 files changed, 439 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
create mode 100644 drivers/clocksource/renesas-ostm.c
--
2.10.1
--
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] i2c: do not enable fall back to Host Notify by default
From: Wolfram Sang @ 2017-01-12 18:41 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Benjamin Tissoires, Pali Rohár,
Michał Kępień, Jean Delvare, Takashi Iwai,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20170105045722.GA17958@dtor-ws>
On Wed, Jan 04, 2017 at 08:57:22PM -0800, Dmitry Torokhov wrote:
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
>
> For DT-based systems we introduce "host-notify" property that we convert
> to I2C_CLIENT_HOST_NOTIFY board flag.
>
> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Applied to for-current, thanks!
How do we handle driver fixes? Shall I take them via I2C to have the
dependency clear? Or can they go seperately?
^ permalink raw reply
* [PATCH v2 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-12 18:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484245772-31511-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..3f2250fc391b 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_find_last_cache_level(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] of: base: add support to find the level of the last cache
From: Sudeep Holla @ 2017-01-12 18:29 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. We can obtain the same by just checking
the level at which the last cache is present. This patch adds support
to find the level of the last cache for a given cpu.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 27 +++++++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 28 insertions(+)
v1->v2:
- Moved to using "cache-level" in the last level cache instead
of counting through all the nodes as suggested by Rob
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..c1128a077aea 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,32 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_find_last_cache_level - Find the level at which the last cache is
+ * present for the given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which the last cache level is needed
+ *
+ * Returns the the level at which the last cache is present. It is exactly
+ * same as the total number of cache levels for the given logical cpu.
+ */
+int of_find_last_cache_level(unsigned int cpu)
+{
+ int cache_level = 0;
+ struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ prev = np;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ if (prev)
+ of_property_read_u32(prev, "cache-level", &cache_level);
+
+ return cache_level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..21e6323de0f3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_find_last_cache_level(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-12 18:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
Now that all the clocks in the boot loader are disabled before booting
the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo
that was missed during original testing.
Fixes: 7c8522b7047c ("ARM: dts: r7s72100: add sdhi clock to device tree")
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
include/dt-bindings/clock/r7s72100-clock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
index 29e01ed..318ab14 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -46,6 +46,6 @@
/* MSTP12 */
#define R7S72100_CLK_SDHI0 3
-#define R7S72100_CLK_SDHI1 2
+#define R7S72100_CLK_SDHI1 1
#endif /* __DT_BINDINGS_CLOCK_R7S72100_H__ */
--
2.10.1
--
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 v2 2/2] Support for DW CSI-2 Host IPK
From: Hans Verkuil @ 2017-01-12 18:06 UTC (permalink / raw)
To: Ramiro Oliveira, robh+dt, mark.rutland, mchehab, devicetree,
linux-kernel, linux-media
Cc: davem, gregkh, geert+renesas, akpm, linux,
laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA, Sakari Ailus
In-Reply-To: <8823670a-8456-87d0-3265-cb427e3445eb@synopsys.com>
On 01/12/2017 06:43 PM, Ramiro Oliveira wrote:
> Hi Hans,
>
> Thank you for your feedback.
>
> On 1/11/2017 11:54 AM, Hans Verkuil wrote:
>> Hi Ramiro,
>>
>> See my review comments below:
>>
>> On 12/12/16 16:00, Ramiro Oliveira wrote:
>>> Add support for the DesignWare CSI-2 Host IP Prototyping Kit
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>
> [snip]
>>> +
>>> +static int vid_dev_subdev_s_power(struct v4l2_subdev *sd, int on)
>>> +{
>>> + return 0;
>>> +}
>>
>> Just drop this empty function, shouldn't be needed.
>>
>
> When I start my system I'm hoping all the subdevs have s_power registered. If it
> doesn't exist should I change the way I handle it, or will the core handle it
> for me?
If it isn't provided, then it is just skipped. The general rule is that
you only provide these ops if they do something useful.
>
>>> +
>>> +static int vid_dev_subdev_registered(struct v4l2_subdev *sd)
>>> +{
>>> + struct video_device_dev *vid_dev = v4l2_get_subdevdata(sd);
>>> + struct vb2_queue *q = &vid_dev->vb_queue;
>>> + struct video_device *vfd = &vid_dev->ve.vdev;
>>> + int ret;
>>> +
>>> + memset(vfd, 0, sizeof(*vfd));
>>> +
>>> + strlcpy(vfd->name, VIDEO_DEVICE_NAME, sizeof(vfd->name));
>>> +
>>> + vfd->fops = &vid_dev_fops;
>>> + vfd->ioctl_ops = &vid_dev_ioctl_ops;
>>> + vfd->v4l2_dev = sd->v4l2_dev;
>>> + vfd->minor = -1;
>>> + vfd->release = video_device_release_empty;
>>> + vfd->queue = q;
>>> +
>>> + INIT_LIST_HEAD(&vid_dev->vidq.active);
>>> + init_waitqueue_head(&vid_dev->vidq.wq);
>>> + memset(q, 0, sizeof(*q));
>>> + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> + q->io_modes = VB2_MMAP | VB2_USERPTR;
>>
>> Add VB2_DMABUF and VB2_READ.
>>
>
> I'll add them, but I'm not using them, is it standard procedure to add them all
> even if they aren't used?
You may not use them, but others might. And it doesn't cost anything to add them.
>
>>> + q->ops = &vb2_video_qops;
>>> + q->mem_ops = &vb2_vmalloc_memops;
>>
>> Why is vmalloc used? Can't you use dma_contig or dma_sg and avoid having to copy
>> the image data? That's a really bad design given the amount of video data that
>> you have to copy.
>>
>
> When I started development, the arch I was using (ARC) didn't support
> dma_contig, so I was forced to use vmalloc.
>
> Since then things have changed and I'm already using dma_contig, however it
> wasn't included in this patch. I'll add it to the next patch.
Ah, good. If you are switching to dma_contig, then remove VB2_USERPTR.
VB2_DMABUF should be used instead.
Regards,
Hans
^ permalink raw reply
* [PATCH v5 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup
From: Rajat Jain @ 2017-01-12 18:01 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <20170112180107.63244-1-rajatja@google.com>
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v5: same as v5
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name
Documentation/devicetree/bindings/net/btusb.txt | 3 ++
.../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++++++++++++++----
drivers/bluetooth/btusb.c | 51 ++++++++++++++++++++++
3 files changed, 92 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (50%)
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c85972..01fa2d4188d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
"usb1286,204e" (Marvell 8997)
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
Optional properties:
- interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63cb0543..9be1059ff03f 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
Required properties:
- compatible : should be one of the following:
- * "marvell,sd8897-bt"
- * "marvell,sd8997-bt"
+ * "marvell,sd8897-bt" (for SDIO)
+ * "marvell,sd8997-bt" (for SDIO)
+ * "usb1286,204e" (for USB)
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
platform. The value will be configured to firmware. This
is needed to work chip's sleep feature as expected (u16).
- interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. Driver will request an irq based
- on this interrupt number. During system suspend, the irq will be
- enabled so that the bluetooth chip can wakeup host platform under
- certain condition. During system resume, the irq will be disabled
+ - interrupt-names: Used only for USB based devices (See below)
+ - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+ driver will use the first interrupt specified in the interrupt
+ array. For USB based devices, the driver will use the interrupt
+ named "wakeup" from the interrupt-names and interrupt arrays.
+ The driver will request an irq based on this interrupt number.
+ During system suspend, the irq will be enabled so that the
+ bluetooth chip can wakeup host platform under certain
+ conditions. During system resume, the irq will be disabled
to make sure unnecessary interrupt is not received.
Example:
@@ -29,7 +39,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-names = "wakeup";
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0a777bb407b1..a1079c19b96f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,50 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ /* Move on if no wakeup pin specified */
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return 0;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2918,6 +2962,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvell devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+ }
#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
--
2.11.0.390.gc69c2f50cf-goog
^ 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