[linux-yocto] Regarding clarifications for adding support of I2C, SPI slave devices on x86 through ACPI

[Ong, Boon Leong]

> -----Original Message-----
> From: Sathish Kumar Balasubramaniam -ERS, HCL Tech [mailto:b-
> sathishkumar at hcl.com]
> Sent: Wednesday, April 16, 2014 4:45 AM
> To: Ong, Boon Leong
> Cc: linux-yocto at yoctoproject.org; Darren Hart (dvhart at linux.intel.com); Chang,
> Rebecca Swee Fun; Chew, Chiau Ee
> Subject: RE: [linux-yocto] Regarding clarifications for adding support of I2C, SPI
> slave devices on x86 through ACPI
> 
> I could see addition of board files for baytrail in the git link you sent.
> 
> By doubt is, why board files are still used in intel while the intel community itself
> does not recommend board files.
> 
It is needed only in PCI enumeration. It is largely due to the clock framework used by
dma, spi & pwm which requires clock information to be available/registered with the
clock during PCI enumeration. This is not needed for ACPI mode.  
 
> I am referring http://events.linuxfoundation.org/sites/events/files/slides/x86-
> platform.pdf
> 
> Correct me if i am wrong ?
>
Yes. The view/opinion of not having board file still stay. 

> Regards,
> B.Sathish Kumar
> ________________________________________
> From: Ong, Boon Leong [boon.leong.ong at intel.com]
> Sent: 15 April 2014 20:28:14
> To: Sathish Kumar Balasubramaniam -ERS, HCL Tech
> Cc: linux-yocto at yoctoproject.org; Darren        Hart (dvhart at linux.intel.com);
> Chang, Rebecca Swee Fun; Chew, Chiau Ee
> Subject: RE: [linux-yocto] Regarding clarifications for adding support of I2C, SPI
> slave devices on x86 through ACPI
> 
> CC'ed Rebecca & Chia Ee for their response/attention.
> 
> Short answer, we have both ACPI and PCI enumeration support for those low
> power IO like I2C, SPI, HS-UART.
> You can refer to http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-
> 3.8/tree/meta/cfg/kernel-cache/features/valleyisland-io?h=meta for v3.8.
> 
> For your knowledge, we are in the midst of making support for v3.10 too and
> we prefer that your long term goal is to converge into Linux LTS/LTSI. But, it is
> fine to try out v3.8 and eventually move to v3.10.
> 
> 
> From: linux-yocto-bounces at yoctoproject.org [mailto:linux-yocto-
> bounces at yoctoproject.org] On Behalf Of Sathish Kumar Balasubramaniam -ERS,
> HCL Tech
> Sent: Tuesday, April 15, 2014 10:41 PM
> To: linux-yocto at yoctoproject.org; Darren Hart (dvhart at linux.intel.com)
> Subject: [linux-yocto] Regarding clarifications for adding support of I2C, SPI
> slave devices on x86 through ACPI
> Importance: High
> 
> Hi,
> 
> For Intel, I can understand that the community is advising to implement the I2C,
> SPI slave devices info like base address, IRQs, etc through ACPI mechanism
> rather than using Board files and FDT
> 
> I read the following
> https://www.kernel.org/doc/Documentation/acpi/enumeration.txt
> https://events.linuxfoundation.org/images/stories/slides/lfcs2013_wysocki.pdf
> 
> In Linux Kernel 3.8 we are trying to add support for (I2C, SPI) slave devices like
> video output decoder, video input decoder, etc which are behind the bus
> controllers
> 
> For ex, for adding support of ADV7180 through I2C
> 
> I have the following clarifications
> 
> 1. Do we need any modification in the BIOS for adding support of I2C, SPI slave
> devices to Linux using ACPI ?
> 2. Do we need to add the CONFIG_ACPI code (described in "I2C serial bus
> support" section of acpi/enumeration.txt) to the drivers/media/i2c/adv7180.c
> file ?
> 3. Where we need to add the device info like I2C bus number, I2C slave address,
> IRQ ?
> 4. Do we need to add any additional code in the chip driver specifically for this
> ACPI support ?
> 5. We have an Intel reference board. The source code provided by Intel itself
> used certain board files to add support for SPI slave devices, Clock setup, Init,
> etc. Why it has been done without using ACPI ? Is it due to any restriction ?
> 
> 
> Thanks,
> B.Sathish Kumar
> 
> 
> ::DISCLAIMER::
> ------------------------------------------------------------------------------------------------------
> ----------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are confidential and intended
> for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as information
> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> may contain viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator or HCL
> or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the author
> and may not necessarily reflect the views or opinions of HCL or its affiliates. Any
> form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of authorized representative of HCL is strictly prohibited. If you have
> received this email in error please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
> 
> ------------------------------------------------------------------------------------------------------
> ----------------------------------------------