Date   

Re: PCI enumeration and IRQ_CONNECT ?

Boie, Andrew P
 

On Mon, 2016-10-17 at 11:48 -0400, Dmitriy Korovkin wrote:
 
Then we need to deal with it's specifics. At one time I tried to configure 
IRQs through PCI legacy module, and it helped, but just partially.
 
What is the specific problem you are seeing?
Are you dealing with interrupts whose properties aren't known at compile time?
Are you saying we need to put dynamic IRQs back in the kernel just to deal with
Galileo? That's not gonna happen..

Andrew


Re: PCI enumeration and IRQ_CONNECT ?

Dmitriy Korovkin
 

On Mon, 17 Oct 2016, Boie, Andrew P wrote:

On Mon, 2016-10-17 at 11:41 -0400, Dmitriy Korovkin wrote:

Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical
or
due to convenience/availability at the time the bring-up is done. The sort
of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards
support.
/Dmitriy
I've raised this with Anas a few times. He can comment here, but my
understanding is that there are still a bunch of people still doing work or
demoing things with Galileo since they were cheap and easy to get ahold of. I
would like to see Galileo removed from the tree as well.

Andrew
Then we need to deal with it's specifics. At one time I tried to configure
IRQs through PCI legacy module, and it helped, but just partially.

/Dmitriy.


Re: Using ARM CMSIS in Zephyr

Boie, Andrew P
 

On Mon, 2016-10-17 at 12:33 +0200, Tomasz Bursztyka wrote:
 > 
My understanding is that as maintainers of the Zephyr kernel, we do not
want to
be in the driver maintenance business if we can get someone else to do
that
instead.
Nobody is going to do the drivers for you the exact way you want it, 
specifically tailored of Zephyr,
optimized for it. ;|
We are fighting everyday to save bytes of rom and ram, not for the 
driver to consume those because of
adaptations layers and so on.

Not to say about code itself not following Zephyr's style.
That's what the policy has been so far.
We got rid of tons of Arduino 101 drivers in favor of just using QMSI's, a copy
of QMSI is now in-tree. I don't think we are using any custom drivers for
Arduino 101 anymore, except maybe IPM which could be replaced with QMSI's
implementation as well.

We also have an open story to implement a shim layer to use the Nios II drivers
in the Altera HAL, at the moment we just have a simple timer and JTAG UART
driver for that platform in our tree.

Andrew


Re: PCI enumeration and IRQ_CONNECT ?

Boie, Andrew P
 

On Mon, 2016-10-17 at 11:41 -0400, Dmitriy Korovkin wrote:
 
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical
or
due to convenience/availability at the time the bring-up is done. The sort
of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards 
support.
/Dmitriy
I've raised this with Anas a few times. He can comment here, but my
understanding is that there are still a bunch of people still doing work or
demoing things with Galileo since they were cheap and easy to get ahold of. I
would like to see Galileo removed from the tree as well.

Andrew


Re: PCI enumeration and IRQ_CONNECT ?

Dmitriy Korovkin
 

On Mon, 17 Oct 2016, Boie, Andrew P wrote:

On Mon, 2016-10-17 at 11:05 -0400, Dmitriy Korovkin wrote:

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical or
due to convenience/availability at the time the bring-up is done. The sort of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.
Then it comes to a question if Zephyr OS should drop the Galileo bards
support.
/Dmitriy

Andrew


Re: PCI enumeration and IRQ_CONNECT ?

Boie, Andrew P
 

On Mon, 2016-10-17 at 11:05 -0400, Dmitriy Korovkin wrote:
 
In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy
Yes but this is not typical of the sort of boards we are targeting.
Galileo is a board that can run Linux. It is not an interesting target for
Zephyr. It is being used for Zephyr for reasons which are largely historical or
due to convenience/availability at the time the bring-up is done. The sort of
MCUs that a lightweight OS like Zephyr targets are not going to have hot-
pluggable PCI busses.

Andrew


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5614 : cmsis: add headers for STM32L4xx
- https://gerrit.zephyrproject.org/r/5606 : serial: qmsi: cleanup uart kconfigs and use global Kconfigs
- https://gerrit.zephyrproject.org/r/5607 : serial: ns16550: Use global UART Kconfigs instead of custom ones
- https://gerrit.zephyrproject.org/r/5610 : serial: stellarus: use global Kconfig for UART
- https://gerrit.zephyrproject.org/r/5604 : drivers: spi: Add SPI_SLAVE flag to allow platform drivers to switch to slave mode
- https://gerrit.zephyrproject.org/r/5613 : serial: altera_jtag: move to global serial Kconfig
- https://gerrit.zephyrproject.org/r/5608 : serial: atmel_sam3: use global Kconfig for UART
- https://gerrit.zephyrproject.org/r/5611 : serial: k20: use global Kconfig for UART
- https://gerrit.zephyrproject.org/r/5612 : serial: stm32: use global Kconfig for UART
- https://gerrit.zephyrproject.org/r/5609 : serial: nsim: use global Kconfig for UART
- https://gerrit.zephyrproject.org/r/5615 : sanity_chk: add nucleo_l476rg board support
- https://gerrit.zephyrproject.org/r/5605 : Bluetooth: L2CAP: Protect BR/EDR core control channels
- https://gerrit.zephyrproject.org/r/5603 : drivers: serial: uart_stm32: Fix typo in register field name
- https://gerrit.zephyrproject.org/r/5599 : Bluetooth: shell: Add sample SDP service registrations
- https://gerrit.zephyrproject.org/r/5602 : drivers: Make drive config info const.
- https://gerrit.zephyrproject.org/r/5601 : pwm/dw: Make config_info pointers const.
- https://gerrit.zephyrproject.org/r/5597 : pinmux: k64f: remove unused Kconfig section

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5202 : pinmux/stm32: add support for up to 16 alternate functions
- https://gerrit.zephyrproject.org/r/5204 : pinmux/stm32: add pinmux definition for i2c
- https://gerrit.zephyrproject.org/r/5201 : stm32lx: add u(s)art driver for the L series
- https://gerrit.zephyrproject.org/r/5516 : unified: Update msgQ doxygen styled function headers
- https://gerrit.zephyrproject.org/r/5532 : unified: Memory map APIs to use size_t
- https://gerrit.zephyrproject.org/r/5531 : unified: Update mem_map doxygen style function headers
- https://gerrit.zephyrproject.org/r/5530 : unified: Add k_mem_map_num_free_get()
- https://gerrit.zephyrproject.org/r/5529 : unified: Remove unused K_MEM_MAP_SIZE() macro
- https://gerrit.zephyrproject.org/r/5362 : unified: Tweak mem_map API parameters
- https://gerrit.zephyrproject.org/r/5339 : unified: Add k_msgq_num_free_get() API
- https://gerrit.zephyrproject.org/r/5476 : unified/doc: Update timing section of Kernel Primer
- https://gerrit.zephyrproject.org/r/5477 : unified: Revise timer code to conform to new API specification
- https://gerrit.zephyrproject.org/r/5442 : net: yaip: Add initial Bluetooth support
- https://gerrit.zephyrproject.org/r/5588 : sensors: tmp112: move tmp112 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5587 : sensors: tmp007: move tmp007 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5586 : sensors: sx9500: move sx9500 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5585 : sensors: sht3xd: move sht3xd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5584 : sensors: mpu6050: move mpu6050 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5583 : sensors: mcp9808: move mcp9808 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5207 : nucleo_l476rg: add board support
- https://gerrit.zephyrproject.org/r/5582 : sensors: max44009: move max44009 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5206 : stm32lx: add i2c driver for the L series
- https://gerrit.zephyrproject.org/r/5581 : sensors: lsm9ds0_mfd: move lsm9ds0_mfd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5580 : sensors: lsm9ds0_gyro: move lsm9ds0_gyro to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5579 : sensors: lsm6ds0: move lsm6ds0 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5578 : sensors: lps25hb: move lps25hb to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5577 : sensors: lis3mdl: move lis3mdl to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5576 : sensors: lis3dh: move lis3dh to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5575 : sensors: isl29035: move isl29035 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5574 : sensors: hts221: move hts221 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5573 : sensors: hp206c: move hp206c to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5572 : sensors: hmc5883l: move hmc5883l to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5571 : sensors: hdc1008: move hdc1008 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5570 : sensors: dht: move dht to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5569 : sensors: bmi160: move bmi160 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5199 : stm32l4: add pinmux for USARTs
- https://gerrit.zephyrproject.org/r/5522 : unified: memory pool APIs to use size_t
- https://gerrit.zephyrproject.org/r/5568 : sensors: bmg160: move bmg160 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5567 : sensors: bme280: move bme280 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5566 : sensors: bmc150_magn: move bmc150_magn to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5565 : sensors: bma280: move bma280 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5564 : sensors: ak8975: move ak8975 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5195 : stm32l4: add clock control driver
- https://gerrit.zephyrproject.org/r/5194 : stm32l4: add initial soc support for stm32l4
- https://gerrit.zephyrproject.org/r/5205 : stm32l4: add pinconf settings for I2C
- https://gerrit.zephyrproject.org/r/5203 : pinmux/stm32: add support for pinmux of port h
- https://gerrit.zephyrproject.org/r/5198 : stm32l4: add exti support
- https://gerrit.zephyrproject.org/r/5197 : stm32_exti: add support for controllers with more than 32 lines
- https://gerrit.zephyrproject.org/r/5200 : stm32l4: add pinconf for USARTs
- https://gerrit.zephyrproject.org/r/5196 : stm32l4: add gpio support for l4
- https://gerrit.zephyrproject.org/r/4921 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/5517 : unified: msgQs to use size_t
- https://gerrit.zephyrproject.org/r/5289 : unified: Remove unused K_MSGQ_SIZE() macro
- https://gerrit.zephyrproject.org/r/5290 : unified: Tweak msgQ API parameters
- https://gerrit.zephyrproject.org/r/5461 : unified: Rework K_THREAD_DEFINE()
- https://gerrit.zephyrproject.org/r/5539 : drivers: Fix type problems when building QMSI rtc driver
- https://gerrit.zephyrproject.org/r/5215 : drivers: exti_stm32: fix clear pending exti
- https://gerrit.zephyrproject.org/r/5214 : exti: stm32: fix driver data handling
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/5436 : i2c/dw: Move RW objects in config_info to driver_data
- https://gerrit.zephyrproject.org/r/5526 : net: Add TODO item for Bluetooth
- https://gerrit.zephyrproject.org/r/5441 : eth/dw: Move RW objects from device config_info to device driver_data.
- https://gerrit.zephyrproject.org/r/5427 : spi/intel: Move RW driver context from config to runtime structure.
- https://gerrit.zephyrproject.org/r/5437 : gpio/dw: Move RW objects in config_info to driver_data
- https://gerrit.zephyrproject.org/r/5171 : samples/mbedtls_dtlsclient: mbedTLS sample DTLS client app.
- https://gerrit.zephyrproject.org/r/4454 : net/yaip: Separate SLIP support into TAP and TUN options
- https://gerrit.zephyrproject.org/r/4562 : Bluetooth: Sample: handsfree sample application
- https://gerrit.zephyrproject.org/r/4917 : iot/zoap: Port to the native stack
- https://gerrit.zephyrproject.org/r/5120 : samples/zoap_client: Use token generator helper
- https://gerrit.zephyrproject.org/r/5119 : iot/zoap: Add helper for generating tokens
- https://gerrit.zephyrproject.org/r/5023 : drivers: clock_control: Add nRF5x Series SoC clock driver
- https://gerrit.zephyrproject.org/r/5525 : ext qmsi: Update to QMSI 1.2 release
- https://gerrit.zephyrproject.org/r/5505 : net: dhcpv4: Adjust DHCPv4 debug config wording.
- https://gerrit.zephyrproject.org/r/5416 : pinmux: Add hexiwear pinmux table
- https://gerrit.zephyrproject.org/r/5415 : hexiwear: Add support for hexiwear board
- https://gerrit.zephyrproject.org/r/5414 : pinmux: Rename frdm_k64f pinmux driver to k64
- https://gerrit.zephyrproject.org/r/5417 : MAINTAINERS: Add frdm-k64f and hexiwear boards
- https://gerrit.zephyrproject.org/r/5418 : sanitycheck: Add hexiwear board
- https://gerrit.zephyrproject.org/r/5536 : unified/arc: add unified kernel support for ARC arch
- https://gerrit.zephyrproject.org/r/5254 : MAINTAINERS: Add maintainer for ARM LTD V2M Beetle Board
- https://gerrit.zephyrproject.org/r/5452 : tests/benchmark/latency_measure: use TC_END_REPORT() to report success
- https://gerrit.zephyrproject.org/r/5431 : samples: add tagging to avoid microkernel running on nano only targets

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5598 : Bluetooth: UUID: Add protocol UUIDs
- https://gerrit.zephyrproject.org/r/5595 : Bluetooth: GATT: Fix code style
- https://gerrit.zephyrproject.org/r/5600 : Bluetooth: UUID: Fix alignment of UUID declarations
- https://gerrit.zephyrproject.org/r/5596 : quark d2000: remove bluetooth configuration from SoC
- https://gerrit.zephyrproject.org/r/5590 : Bluetooth: GATT: Pass CCC attribute to changed callback
- https://gerrit.zephyrproject.org/r/5097 : iot/zoap: Add support for error 4.15
- https://gerrit.zephyrproject.org/r/5096 : zoap: Fix alignment of multiline function arguments
- https://gerrit.zephyrproject.org/r/5510 : net: nbuf: Make sure ll_reserve is not holding previous value
- https://gerrit.zephyrproject.org/r/5513 : net: driver: SLIP does not need to store ll reserve at any time
- https://gerrit.zephyrproject.org/r/5514 : net: drivers: slip: Let's cleanup a bit for better readability
- https://gerrit.zephyrproject.org/r/5512 : net: drivers: Slip can get the MTU set on it's interface
- https://gerrit.zephyrproject.org/r/5511 : net: drivers: SLIP should not reserve anything while receiving
- https://gerrit.zephyrproject.org/r/5509 : net: ethernet: Update the data pointer according to ll reserve
- https://gerrit.zephyrproject.org/r/5130 : Bluetooth: Controller: Alternate Enc procedure for nRF51x SoC
- https://gerrit.zephyrproject.org/r/5450 : samples/zoap_server: Add preliminary support for validation
- https://gerrit.zephyrproject.org/r/5379 : samples: TH02 temperature and humidity sensor sample
- https://gerrit.zephyrproject.org/r/5378 : sensors: add TH02 temperature sensor (Grove)
- https://gerrit.zephyrproject.org/r/5380 : grove lcd: cleanup includes
- https://gerrit.zephyrproject.org/r/5507 : samples: drivers: dma: Improve failure debug granularity
- https://gerrit.zephyrproject.org/r/5594 : Merge bluetooth branch into master


Re: PCI enumeration and IRQ_CONNECT ?

Dmitriy Korovkin
 

On Sun, 16 Oct 2016, Boie, Andrew P wrote:

On Wed, 2016-10-12 at 10:59 +0100, Marcus Shawcroft wrote:
Hi,

A question has come up in one of the config_info refactor patches
about the relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the
driver context.
- irq_enable() is called to enable the  irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number
(e.g CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.
This might be some cruft that should be fixed. Even on a PCI board like Galileo,
the IRQ lines are fixed in HW so IRQ_CONNECT() uses (and can only use due to the
way it is implemented) defined constants.

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.
And by "something pathological" you mean insertion of an external card.
PCI_ENUMERATION is enabled for Galileo exactly for this reason.
/Dmitriy

Andrew


Re: Using ARM CMSIS in Zephyr

Tomasz Bursztyka
 

Hi,

On 16 October 2016 at 23:03, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:
On Fri, 2016-10-14 at 07:48 +0000, Cufi, Carles wrote:
- What are the long term plans on using CMSIS?
I have asked myself the same question.
My understanding is that as maintainers of the Zephyr kernel, we do not want to
be in the driver maintenance business if we can get someone else to do that
instead.
Nobody is going to do the drivers for you the exact way you want it,
specifically tailored of Zephyr,
optimized for it. ;|
We are fighting everyday to save bytes of rom and ram, not for the
driver to consume those because of
adaptations layers and so on.

Not to say about code itself not following Zephyr's style.


So if generic drivers exist for a particular arch/platform (QMSI, CMSIS, etc) I
think we want to use them instead and drop any local implementations from the
tree.
Adopting drivers in this manner provides a route to broaden the
driver coverage quickly. However, in some circumstances it may prove
beneficial on a case by case basis to provide native drivers that have
different characteristics to off the shelf drivers. For example zephyr
might prefer to provide native drivers that take a different position
on ram footprint, power efficiency or have interfaces that mesh better
with Zephyr.

Cheers
/Marcus
I fully agree on this. Best possible would be to have native drivers only.

Now, that's my technical point of view.
Reality is about work resource, and writing drivers takes quite some dev
hours.
Thus the trade-offs I guess.

Tomasz


Re: Using ARM CMSIS in Zephyr

Piotr Mienkowski <piotr.mienkowski@...>
 

However, in some circumstances it may prove beneficial on a case by case
basis to provide native drivers that have different characteristics to off the
shelf drivers.
I'm also in favor of providing native driver support on case by case basis. There are some vendors, notably Atmel, that publish drivers good enough to showcase their products, having some nice features here and there but being low quality overall and not especially useful for any serious development.

I find relying on vendor's code which is not developed following an open source model, one that makes it possible to submit patches and be confident that bugs will finally be fixed problematic.

Cheers,
Piotr


Re: Using ARM CMSIS in Zephyr

Piotr Mienkowski <piotr.mienkowski@...>
 

On the whole it sounds like CMSIS v5 will resolve any concerns about
licensing so rather than quibble about licensing it how to classify
drivers if might be best to plot a gung-ho path to CMSIS v5!
For those who haven't looked it up themselves yet, from https://github.com/ARM-software/CMSIS_5

"CMSIS Version 5.0.0 is now available as beta release, but will need further refinement as we are reviewing the feedback that we have got via various channels. We are scheduling the final release for November 2016."

One thing to keep in mind about CMSIS is that it does not provide support for assembler, so any assembler code in Zephyr's code base that is accessing SCB or other core registers won't be able to simply include CMSIS header.


Re: Using ARM CMSIS in Zephyr

Marcus Shawcroft <marcus.shawcroft@...>
 

On 16 October 2016 at 23:03, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:
On Fri, 2016-10-14 at 07:48 +0000, Cufi, Carles wrote:

- What are the long term plans on using CMSIS?
I have asked myself the same question.
My understanding is that as maintainers of the Zephyr kernel, we do not want to
be in the driver maintenance business if we can get someone else to do that
instead.

So if generic drivers exist for a particular arch/platform (QMSI, CMSIS, etc) I
think we want to use them instead and drop any local implementations from the
tree.
Adopting drivers in this manner provides a route to broaden the
driver coverage quickly. However, in some circumstances it may prove
beneficial on a case by case basis to provide native drivers that have
different characteristics to off the shelf drivers. For example zephyr
might prefer to provide native drivers that take a different position
on ram footprint, power efficiency or have interfaces that mesh better
with Zephyr.

Cheers
/Marcus


Re: Using ARM CMSIS in Zephyr

Boie, Andrew P
 

On Fri, 2016-10-14 at 07:48 +0000, Cufi, Carles wrote:
 
- What are the long term plans on using CMSIS?
I have asked myself the same question.
My understanding is that as maintainers of the Zephyr kernel, we do not want to
be in the driver maintenance business if we can get someone else to do that
instead.

So if generic drivers exist for a particular arch/platform (QMSI, CMSIS, etc) I
think we want to use them instead and drop any local implementations from the
tree.

Andrew


Re: PCI enumeration and IRQ_CONNECT ?

Boie, Andrew P
 

On Wed, 2016-10-12 at 10:59 +0100, Marcus Shawcroft wrote:
Hi,

A question has come up in one of the config_info refactor patches
about the relationship between PCI enumeration and IRQ_CONNECT.... (
https://gerrit.zephyrproject.org/r/#/c/5427/2 )

Can anyone shed some light on how PCI enumeration and IRQ_CONNECT
interact in the DW GPIO, I2C and SPI drivers?

Specifically, the initialization of these drivers appears to be that:
- PCI enumeration populates driver_data->pci_dev via a call to pci_bus_scan()
- irq_num is pulled out of the pci_dev structure and stored in the
driver context.
- irq_enable() is called to enable the  irq_num
- IRQ_CONNECT() is called to connect a hardwired (static) IRQ number
(e.g CONFIG_INTEL_PORT_0_IRQ) to the interrupt service routine.

Hence we have an statically configured interrupt number passed to
IRQ_CONNECT() and an irq_num returned from PCI enumeration, and no
obvious connection between the two.
This might be some cruft that should be fixed. Even on a PCI board like Galileo,
the IRQ lines are fixed in HW so IRQ_CONNECT() uses (and can only use due to the
way it is implemented) defined constants.

In other words, the irq_num pulled out of PCI enumeration doesn't need to be
used/stored and we should just use the defined constant everywhere. Unless
something pathological is going on they should be the same value.

Andrew


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5594 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/5589 : arc: Support FIRQ handling when CONFIG_RGF_NUM_BANKS==1
- https://gerrit.zephyrproject.org/r/5593 : unified: doxygen comments for semaphores.
- https://gerrit.zephyrproject.org/r/5590 : Bluetooth: GATT: Pass CCC attribute to changed callback

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5231 : arch/arm: add initial support for Cortex-M0/M0+
- https://gerrit.zephyrproject.org/r/5442 : net: yaip: Add initial Bluetooth support
- https://gerrit.zephyrproject.org/r/5526 : net: Add TODO item for Bluetooth
- https://gerrit.zephyrproject.org/r/5528 : Bluetooth: conn: Add support for sending fragmented buffers
- https://gerrit.zephyrproject.org/r/5573 : sensors: hp206c: move hp206c to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5587 : sensors: tmp007: move tmp007 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5585 : sensors: sht3xd: move sht3xd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5581 : sensors: lsm9ds0_mfd: move lsm9ds0_mfd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5583 : sensors: mcp9808: move mcp9808 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5580 : sensors: lsm9ds0_gyro: move lsm9ds0_gyro to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5579 : sensors: lsm6ds0: move lsm6ds0 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5588 : sensors: tmp112: move tmp112 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5586 : sensors: sx9500: move sx9500 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5578 : sensors: lps25hb: move lps25hb to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5571 : sensors: hdc1008: move hdc1008 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5023 : drivers: clock_control: Add nRF5x Series SoC clock driver
- https://gerrit.zephyrproject.org/r/5024 : arm: nordic_nrf5: Select clock control for BLE controller
- https://gerrit.zephyrproject.org/r/5572 : sensors: hmc5883l: move hmc5883l to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5582 : sensors: max44009: move max44009 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5584 : sensors: mpu6050: move mpu6050 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5574 : sensors: hts221: move hts221 to own directory under drivers/sensor/

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5591 : Bluetooth: tests: Clean up platform whitelisting
- https://gerrit.zephyrproject.org/r/5592 : Bluetooth: tests: Limit BR/EDR tests to only qemu
- https://gerrit.zephyrproject.org/r/5118 : eth: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/5562 : Bluetooth: SMP: Take advantage of new byte swap helpers
- https://gerrit.zephyrproject.org/r/5438 : serial/ns16550: Move RW objects from driver config to driver context.
- https://gerrit.zephyrproject.org/r/5440 : tests: Add ethernet drivers to drivers/build_all
- https://gerrit.zephyrproject.org/r/5439 : board: Enable ETH_DW for quark_x1000 if ETHERNET is enabled.
- https://gerrit.zephyrproject.org/r/5435 : spi/dw: Make config structure static.
- https://gerrit.zephyrproject.org/r/5560 : win-build: corrects scripts_path for windows build.
- https://gerrit.zephyrproject.org/r/5561 : check_link_map: Removing unsuported python version.


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-1073] compile error in "kernel/unified/idle.c" with CONFIG_SYS_POWER_MANAGEMENT=y
https://jira.zephyrproject.org/browse/ZEP-1073

[ZEP-1070] missing header file to list hpet timer registers
https://jira.zephyrproject.org/browse/ZEP-1070

[ZEP-1072] cotext_m_systick programmed cycles are 1.7 tick less than expected, for tickless idle
https://jira.zephyrproject.org/browse/ZEP-1072

[ZEP-1071] "sys_clock_hw_cycles_per_tick" for hpet timer?
https://jira.zephyrproject.org/browse/ZEP-1071

[ZEP-1069] [TCF] 18 kernel sanity tests fail for EMSK
https://jira.zephyrproject.org/browse/ZEP-1069

[ZEP-1068] [TCF] samples/net/test_15_4 build fail for EMSK
https://jira.zephyrproject.org/browse/ZEP-1068

[ZEP-1074] ATT retrying misbehaves when ATT insufficient Authentication is received
https://jira.zephyrproject.org/browse/ZEP-1074


UPDATED JIRA items within last 24 hours: 8
[ZEP-591] MQTT Port to New IP Stack
https://jira.zephyrproject.org/browse/ZEP-591

[ZEP-1006] Extend soc_flash_qmsi driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1006

[ZEP-1011] Extend usb_dc_dw driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1011

[ZEP-1003] Extend aio_comparator_qmsi driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1003

[ZEP-1004] Extend counter_qmsi_aon driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1004

[ZEP-1005] Extend dma_qmsi driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1005

[ZEP-1008] Extend pwm_qmsi driver to support save/restore peripheral context
https://jira.zephyrproject.org/browse/ZEP-1008

[ZEP-1051] mpool allocation failed after defrag twice...
https://jira.zephyrproject.org/browse/ZEP-1051


CLOSED JIRA items within last 24 hours: 3
[ZEP-910] (Fixed) Adapt tickless idle for x86
https://jira.zephyrproject.org/browse/ZEP-910

[ZEP-471] (Fixed) Ethernet packet with multicast address is not working
https://jira.zephyrproject.org/browse/ZEP-471

[ZEP-577] (Fixed) Sample application source does not compile on Windows
https://jira.zephyrproject.org/browse/ZEP-577


RESOLVED JIRA items within last 24 hours: 2
[ZEP-909] (Fixed) Adapt tickless idle + power management for ARM
https://jira.zephyrproject.org/browse/ZEP-909

[ZEP-1031] (Fixed) qmsi: dma: driver test fails with LLVM
https://jira.zephyrproject.org/browse/ZEP-1031


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/5577 : sensors: lis3mdl: move lis3mdl to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5570 : sensors: dht: move dht to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5569 : sensors: bmi160: move bmi160 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5576 : sensors: lis3dh: move lis3dh to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5566 : sensors: bmc150_magn: move bmc150_magn to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5587 : sensors: tmp007: move tmp007 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5585 : sensors: sht3xd: move sht3xd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5565 : sensors: bma280: move bma280 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5572 : sensors: hmc5883l: move hmc5883l to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5573 : sensors: hp206c: move hp206c to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5588 : sensors: tmp112: move tmp112 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5575 : sensors: isl29035: move isl29035 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5584 : sensors: mpu6050: move mpu6050 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5574 : sensors: hts221: move hts221 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5586 : sensors: sx9500: move sx9500 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5571 : sensors: hdc1008: move hdc1008 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5583 : sensors: mcp9808: move mcp9808 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5581 : sensors: lsm9ds0_mfd: move lsm9ds0_mfd to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5580 : sensors: lsm9ds0_gyro: move lsm9ds0_gyro to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5579 : sensors: lsm6ds0: move lsm6ds0 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5578 : sensors: lps25hb: move lps25hb to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5582 : sensors: max44009: move max44009 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5568 : sensors: bmg160: move bmg160 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5567 : sensors: bme280: move bme280 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5564 : sensors: ak8975: move ak8975 to own directory under drivers/sensor/
- https://gerrit.zephyrproject.org/r/5562 : Bluetooth: SMP: Take advantage of new byte swap helpers
- https://gerrit.zephyrproject.org/r/5547 : samples: usb: Sample to demo USB Mass Storage support
- https://gerrit.zephyrproject.org/r/5539 : drivers: Fix type problems when building QMSI rtc driver
- https://gerrit.zephyrproject.org/r/5545 : usb: Expose end-point stall APIs
- https://gerrit.zephyrproject.org/r/5546 : usb: class: Add USB mass storage class support.
- https://gerrit.zephyrproject.org/r/5540 : unified/arc: Add tickless idle test for Arduino 101 ARC core
- https://gerrit.zephyrproject.org/r/5538 : unified: Add tickless idle support for ARC
- https://gerrit.zephyrproject.org/r/5536 : unified/arc: add unified kernel support for ARC arch
- https://gerrit.zephyrproject.org/r/5537 : unified/arc: add memory pools support for ARC architecture

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5024 : arm: nordic_nrf5: Select clock control for BLE controller
- https://gerrit.zephyrproject.org/r/5023 : drivers: clock_control: Add nRF5x Series SoC clock driver
- https://gerrit.zephyrproject.org/r/5440 : tests: Add ethernet drivers to drivers/build_all
- https://gerrit.zephyrproject.org/r/5435 : spi/dw: Make config structure static.
- https://gerrit.zephyrproject.org/r/5436 : i2c/dw: Move RW objects in config_info to driver_data
- https://gerrit.zephyrproject.org/r/5437 : gpio/dw: Move RW objects in config_info to driver_data
- https://gerrit.zephyrproject.org/r/5439 : board: Enable ETH_DW for quark_x1000 if ETHERNET is enabled.
- https://gerrit.zephyrproject.org/r/5438 : serial/ns16550: Move RW objects from driver config to driver context.
- https://gerrit.zephyrproject.org/r/5441 : eth/dw: Move RW objects from device config_info to device driver_data.
- https://gerrit.zephyrproject.org/r/5427 : spi/intel: Move RW driver context from config to runtime structure.
- https://gerrit.zephyrproject.org/r/5231 : arch/arm: add initial support for Cortex-M0/M0+
- https://gerrit.zephyrproject.org/r/5476 : unified/doc: Update timing section of Kernel Primer
- https://gerrit.zephyrproject.org/r/5461 : unified: Rework K_THREAD_DEFINE()
- https://gerrit.zephyrproject.org/r/5532 : unified: Memory map APIs to use size_t
- https://gerrit.zephyrproject.org/r/5531 : unified: Update mem_map doxygen style function headers
- https://gerrit.zephyrproject.org/r/5362 : unified: Tweak mem_map API parameters
- https://gerrit.zephyrproject.org/r/5530 : unified: Add k_mem_map_num_free_get()
- https://gerrit.zephyrproject.org/r/5529 : unified: Remove unused K_MEM_MAP_SIZE() macro
- https://gerrit.zephyrproject.org/r/5497 : boards: Add support for the nRF51 DK board (PCA10028)
- https://gerrit.zephyrproject.org/r/4635 : serial: make nrf5 driver compatible with nrf51
- https://gerrit.zephyrproject.org/r/5171 : samples/mbedtls_dtlsclient: mbedTLS sample DTLS client app.
- https://gerrit.zephyrproject.org/r/5378 : sensors: add TH02 temperature sensor (Grove)
- https://gerrit.zephyrproject.org/r/5379 : samples: TH02 temperature and humidity sensor sample
- https://gerrit.zephyrproject.org/r/5029 : release notes: add release notes doc
- https://gerrit.zephyrproject.org/r/5522 : unified: memory pool APIs to use size_t
- https://gerrit.zephyrproject.org/r/5521 : unified: Update mem_pool doxygen style function headers
- https://gerrit.zephyrproject.org/r/5353 : unified: Tweak K_MEMORY_POOL_DEFINE() macro
- https://gerrit.zephyrproject.org/r/5520 : unified: Remove unused K_MEM_POOL_SIZE() macro
- https://gerrit.zephyrproject.org/r/5517 : unified: msgQs to use size_t
- https://gerrit.zephyrproject.org/r/5516 : unified: Update msgQ doxygen styled function headers
- https://gerrit.zephyrproject.org/r/5290 : unified: Tweak msgQ API parameters
- https://gerrit.zephyrproject.org/r/5339 : unified: Add k_msgq_num_free_get() API
- https://gerrit.zephyrproject.org/r/4116 : Bluetooth: btp: Add Address Type to Read Controller Information rsp
- https://gerrit.zephyrproject.org/r/5460 : Bluetooth: btp: Include Private Address generation interval
- https://gerrit.zephyrproject.org/r/5261 : pinmux: Add support for ARM LTD V2M Beetle Initialization
- https://gerrit.zephyrproject.org/r/5454 : build: introduce a one-place switch to force using the unified kernel
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/5268 : board_beetle: Enable CMSDK APB UART driver
- https://gerrit.zephyrproject.org/r/5267 : serial: Add driver for CMSDK APB UART

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5560 : win-build: corrects scripts_path for windows build.
- https://gerrit.zephyrproject.org/r/5561 : check_link_map: Removing unsuported python version.
- https://gerrit.zephyrproject.org/r/5563 : misc: fix off-by-one error in sys_memcpy_swap's assert
- https://gerrit.zephyrproject.org/r/5534 : unified: Relocate mailbox doxygen style function headers
- https://gerrit.zephyrproject.org/r/5535 : unified: Mailboxes to use size_t
- https://gerrit.zephyrproject.org/r/5533 : unified: Tweak mailbox API parameters
- https://gerrit.zephyrproject.org/r/5542 : unified: Tweak pipe API parameters
- https://gerrit.zephyrproject.org/r/5541 : unified: Remove unused K_PIPE_SIZE() macro
- https://gerrit.zephyrproject.org/r/5543 : unified: Conditionally declare k_pipe_block_put()
- https://gerrit.zephyrproject.org/r/5544 : unified: Fix bug in memory pool defragmentation code (ZEP-1051)
- https://gerrit.zephyrproject.org/r/5385 : gpio/sam3: Move RW data from driver config to runtime.
- https://gerrit.zephyrproject.org/r/5384 : i2c/sam3: Make config_info pointers const.
- https://gerrit.zephyrproject.org/r/5390 : serial/uart_qmsi: Make pointers to config_info const.
- https://gerrit.zephyrproject.org/r/5389 : i2c/qmsi: Make pointers to config_info const.
- https://gerrit.zephyrproject.org/r/5424 : i2c/qmsi_ss: Make pointers to config_info const.
- https://gerrit.zephyrproject.org/r/5426 : quark_se: Make ipm console config structure static.
- https://gerrit.zephyrproject.org/r/5393 : pwm: qmsi: Remove RW data from driver config structure.
- https://gerrit.zephyrproject.org/r/5382 : quark: ipm: Make driver config structures static.
- https://gerrit.zephyrproject.org/r/5388 : qmsi/dma: Remove unused channel[] from config_info
- https://gerrit.zephyrproject.org/r/5387 : qmsi/dma: Make config_info pointers const.
- https://gerrit.zephyrproject.org/r/5425 : ipm: Make config_info pointers const.
- https://gerrit.zephyrproject.org/r/5381 : tests: test_ipm: Make device config structures static.
- https://gerrit.zephyrproject.org/r/5458 : tests: Add a unit test for the byteorder buffer swap utilities
- https://gerrit.zephyrproject.org/r/5502 : MAINTAINERS: Update ARM & overall maintainer
- https://gerrit.zephyrproject.org/r/5457 : byteorder: Add buffer swap helpers
- https://gerrit.zephyrproject.org/r/5519 : unified: rename sched.h to ksched.h
- https://gerrit.zephyrproject.org/r/5518 : unified: align prototype and definition of k_thread_priority_set
- https://gerrit.zephyrproject.org/r/5459 : Bluetooth: tester: Add GAP Unpair command handler


Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi both

I have referred some generic links for 3 wire SPI connection
https://community.nxp.com/thread/346298
http://www.totalphase.com/support/articles/200350046-Interfacing-with-3-wire-SPI

They have used a resistor in between MOSI and MISO.

So on following the above we need resistor .. Is that Ok ?


Best regards

Mahendravarman Rajarao
RBEI/EAA


From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Saturday, October 15, 2016 12:52 AM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Hi Tomasz,

I do not think a resistor is needed.

Let's use a different example.

I use quark SPI controller to program WinBond SPI flash or Fujitsu FRAM (SPI). I connect all four wires from the SPI controller to the corresponding pins on the spi flash or fram. I do spi write only.
For this case, MISO on the slave side is high-Z state. MISO on the controller side is floating. Do we need a resistor for this? No. The LCD case is similar to this. Why do we need a resistor there?

Thanks
Baohong

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, October 13, 2016 11:53 PM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: Re: Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Hi Baohong,
Hi Tomasz and all,

I guess that the SPI controller in quark may be able to support this. Here is what you need to do.


1. Set spi frame size to 9.

2. Connect the three pins (CS, SCLK,MOSI) to the LCD slave.

3. Combine A0 and the 8-bit data into one 32-bit word (A0 is the 8th bit, D0 to D7 is the 0th to 7th bits, and all the other bits are 0s), and send it to tx fifo.

4. You should be able to see the thing on LCD.

Yes the protocol is not what bothers me.


We do not need a 3-wire SPI controller. We just do not use one of the pins which is MISO.

That's the thing I am not sure it's possible or not.

I did not read anything on DW specs that tells anything about how it behaves with or without MISO being connected.

That said, it should be possible then to fake the line by routing MOSI to MISO as well
with a tiny resistor in the middle, (which ohm value I don't know of).
A superb schema to visualize this:

MOSI --------> slave
|
R
|
MISO

Tomasz


Thanks
Baohong

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, October 13, 2016 7:42 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Cc: cjordan(a)synopsys.com<mailto:cjordan(a)synopsys.com>
Subject: [devel] Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Hi,

I am not aware of DW SPI controller supporting 3-wire configuration.

@Chuck?

Tomasz
Hi

Please help me on the following

We are using Atlas peak and connected LCD in the SPI interface.
The LCD manufacturer preferred to use only 3 wire SPI ( SCLK, SPI_CS, MOSI) along with 9 bit clock
Screenshot of the clock signals of LCD attached


1. We need to give transfer mode of SPI as transmit only . can we directly add cfg->transfer_mode = QM_SPI_TMOD_TX in spi_qmsi.c

2. In order to support 9 bit SPI clock what needs to be added in .config of spi_configure ?

Thanks

Best regards

Mahendravarman Rajarao
RBEI/EAA


Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Liu, Baohong
 

Hi Tomasz,

I do not think a resistor is needed.

Let's use a different example.

I use quark SPI controller to program WinBond SPI flash or Fujitsu FRAM (SPI). I connect all four wires from the SPI controller to the corresponding pins on the spi flash or fram. I do spi write only.
For this case, MISO on the slave side is high-Z state. MISO on the controller side is floating. Do we need a resistor for this? No. The LCD case is similar to this. Why do we need a resistor there?

Thanks
Baohong

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, October 13, 2016 11:53 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Hi Baohong,
Hi Tomasz and all,

I guess that the SPI controller in quark may be able to support this. Here is what you need to do.


1. Set spi frame size to 9.

2. Connect the three pins (CS, SCLK,MOSI) to the LCD slave.

3. Combine A0 and the 8-bit data into one 32-bit word (A0 is the 8th bit, D0 to D7 is the 0th to 7th bits, and all the other bits are 0s), and send it to tx fifo.

4. You should be able to see the thing on LCD.

Yes the protocol is not what bothers me.



We do not need a 3-wire SPI controller. We just do not use one of the pins which is MISO.

That's the thing I am not sure it's possible or not.

I did not read anything on DW specs that tells anything about how it behaves with or without MISO being connected.

That said, it should be possible then to fake the line by routing MOSI to MISO as well
with a tiny resistor in the middle, (which ohm value I don't know of).
A superb schema to visualize this:

MOSI --------> slave
|
R
|
MISO

Tomasz



Thanks
Baohong

From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, October 13, 2016 7:42 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Cc: cjordan(a)synopsys.com<mailto:cjordan(a)synopsys.com>
Subject: [devel] Re: Reg: Transfer mode & 9 bit mode in QMSI SPI driver

Hi,

I am not aware of DW SPI controller supporting 3-wire configuration.

@Chuck?

Tomasz
Hi

Please help me on the following

We are using Atlas peak and connected LCD in the SPI interface.
The LCD manufacturer preferred to use only 3 wire SPI ( SCLK, SPI_CS, MOSI) along with 9 bit clock
Screenshot of the clock signals of LCD attached


1. We need to give transfer mode of SPI as transmit only . can we directly add cfg->transfer_mode = QM_SPI_TMOD_TX in spi_qmsi.c

2. In order to support 9 bit SPI clock what needs to be added in .config of spi_configure ?

Thanks

Best regards

Mahendravarman Rajarao
RBEI/EAA


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-1065] Have the kernel give the leftover memory to the IP stack
https://jira.zephyrproject.org/browse/ZEP-1065

[ZEP-1067] Driver for BMM150
https://jira.zephyrproject.org/browse/ZEP-1067

[ZEP-1066] tests/crypto/test_ecc_dsa fails on qemu_x86 (core dump/time out)
https://jira.zephyrproject.org/browse/ZEP-1066

[ZEP-1064] Fix wiki section coding standards/include paths
https://jira.zephyrproject.org/browse/ZEP-1064


UPDATED JIRA items within last 24 hours: 39
[ZEP-823] New IP Stack - Documentation
https://jira.zephyrproject.org/browse/ZEP-823

[ZEP-825] Porting guide for old-to-new IP Stack APIs
https://jira.zephyrproject.org/browse/ZEP-825

[ZEP-824] Network Device Driver Porting Guide
https://jira.zephyrproject.org/browse/ZEP-824

[ZEP-808] IPv6 Stateless Autoconfiguration (SLAAC)
https://jira.zephyrproject.org/browse/ZEP-808

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

[ZEP-805] Internet Control Message Protocol (ICMP) v6
https://jira.zephyrproject.org/browse/ZEP-805

[ZEP-807] Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-807

[ZEP-794] Requirements for Internet Hosts - Communication Layers
https://jira.zephyrproject.org/browse/ZEP-794

[ZEP-804] IPv6 Addressing Architecture
https://jira.zephyrproject.org/browse/ZEP-804

[ZEP-798] IPv6
https://jira.zephyrproject.org/browse/ZEP-798

[ZEP-791] TCP
https://jira.zephyrproject.org/browse/ZEP-791

[ZEP-812] Compression Format for IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-812

[ZEP-813] RPL: IPv6 Routing Protocol
https://jira.zephyrproject.org/browse/ZEP-813

[ZEP-814] Routing Metrics used in Path Selection
https://jira.zephyrproject.org/browse/ZEP-814

[ZEP-817] Neighbor Discovery Optimization for IPv6 over 6LowPAN
https://jira.zephyrproject.org/browse/ZEP-817

[ZEP-815] Objective Function Zero for RPL
https://jira.zephyrproject.org/browse/ZEP-815

[ZEP-816] Minimum Rank with Hysteresis (RPL)
https://jira.zephyrproject.org/browse/ZEP-816

[ZEP-811] The Trickle Algorithm
https://jira.zephyrproject.org/browse/ZEP-811

[ZEP-883] IP Stack L2 Interface Management API
https://jira.zephyrproject.org/browse/ZEP-883

[ZEP-827] HTTP Client sample application
https://jira.zephyrproject.org/browse/ZEP-827

[ZEP-886] 802.15.4 - MAC command frame support
https://jira.zephyrproject.org/browse/ZEP-886

[ZEP-818] CoAP working over the new IP stack
https://jira.zephyrproject.org/browse/ZEP-818

[ZEP-788] UDP
https://jira.zephyrproject.org/browse/ZEP-788

[ZEP-885] 802.15.4 - Beacon frame support
https://jira.zephyrproject.org/browse/ZEP-885

[ZEP-875] 6LoWPAN - Context based compression support
https://jira.zephyrproject.org/browse/ZEP-875

[ZEP-792] ARP
https://jira.zephyrproject.org/browse/ZEP-792

[ZEP-879] 6LoWPAN - Stateless Address Autoconfiguration
https://jira.zephyrproject.org/browse/ZEP-879

[ZEP-648] New CoAP Implementation
https://jira.zephyrproject.org/browse/ZEP-648

[ZEP-884] 802.15.4 - CSMA-CA Radio protocol support
https://jira.zephyrproject.org/browse/ZEP-884

[ZEP-859] Migrate ENC28J60 driver to YAIP IP stack
https://jira.zephyrproject.org/browse/ZEP-859

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

[ZEP-19] IPSP node support
https://jira.zephyrproject.org/browse/ZEP-19

[ZEP-789] IPv4
https://jira.zephyrproject.org/browse/ZEP-789

[ZEP-790] ICMPv4
https://jira.zephyrproject.org/browse/ZEP-790

[ZEP-365] Zephyr's MQTT library
https://jira.zephyrproject.org/browse/ZEP-365

[ZEP-346] Provide a HTTP library within Zephyr
https://jira.zephyrproject.org/browse/ZEP-346

[ZEP-847] IoT protocol functionality must be moved from samples to lib/iot
https://jira.zephyrproject.org/browse/ZEP-847

[ZEP-735] Several Tests and Samples are broken for CONFIG_DEBUG
https://jira.zephyrproject.org/browse/ZEP-735


CLOSED JIRA items within last 24 hours: 2
[ZEP-844] (Fixed) flashing "arduino_101_sss" build onto Arduino 101 breaks DFU
https://jira.zephyrproject.org/browse/ZEP-844

[ZEP-1026] (Fixed) net/yaip/nbuf: net_nbuf_read does not handle the offset parameter correctly
https://jira.zephyrproject.org/browse/ZEP-1026


RESOLVED JIRA items within last 24 hours: 4
[ZEP-715] (Fixed) Add K64F clock configurations
https://jira.zephyrproject.org/browse/ZEP-715

[ZEP-717] (Fixed) Add ksdk I2C shim driver
https://jira.zephyrproject.org/browse/ZEP-717

[ZEP-1025] (Fixed) Unified kernel build sometimes breaks on a missing .d dependency file.
https://jira.zephyrproject.org/browse/ZEP-1025

[ZEP-1013] (Fixed) [TCF] samples/shell/microkernel build fail
https://jira.zephyrproject.org/browse/ZEP-1013

6341 - 6360 of 8098