On Mon, Sep 25, 2023 at 06:16:29PM +0800, yang tylor wrote: > On Mon, Sep 25, 2023 at 4:41 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote: > > > > On Mon, Sep 25, 2023 at 09:44:21AM +0800, yang tylor wrote: > > > On Fri, Sep 22, 2023 at 11:31 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Sep 22, 2023 at 05:43:54PM +0800, yang tylor wrote: > > > > > On Fri, Sep 22, 2023 at 5:22 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Fri, Sep 22, 2023 at 03:56:25PM +0800, yang tylor wrote: > > > > > > > On Tue, Sep 19, 2023 at 7:09 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Sep 19, 2023 at 05:31:29PM +0800, yang tylor wrote: > > > > > > > > > > > > > > > The behavior of "himax,boot_time_fw_upgrade" seems not stable and > > > > > > > > > should be removed. "himax,fw_in_flash", I use the kernel config for > > > > > > > > > user to select. > > > > > > > > > > > > > > > > That seems like a bad idea, we want to be able to build one kernel that > > > > > > > > works for all hardware at the same time. > > > > > > > > > > > > > > > I see, so I should take that back? > > > > > > > I'll explain more about it. > > > > > > > > > > > > Are there particular ICs where the firmware would always be in flash and > > > > > > others where it would never be? Or is this a choice made by the board or > > > > > > system designer? > > > > > > > > > > > Most cases it's about the system designer's decision. But some ICs may be forced > > > > > to use flash because of its architecture(multiple IC inside, need to > > > > > load firmware to > > > > > multiple IC's sram by master IC). But if there is no limitation on > > > > > this part, most system > > > > > designers will prefer flashless. > > > > > > > > Forgive me if I am not understanding correctly, there are some ICs that > > > > will need to load the firmware from flash and there are some where it > > > > will be a decision made by the designer of the board. Is the flash part > > > > of the IC or is it an external flash chip? > > > > > > > > > > Both are possible, it depends on the IC type. For TDDI, the IC is long > > > and thin, placed on panel PCB, flash will be located at the external > > > flash chip. For the OLED TP, IC is usually placed at FPC and its flash > > > is embedded, thus the IC size is large compared to TDDI. But from the > > > driver's perspective either external flash or embedded flash, the IC > > > itself will load firmware from flash automatically when reset pin is > > > released. Only if firmware is loading from the host storage system, > > > the driver needs to operate the IC in detail. > > > > > > Since there are ICs that can use the external flash or have it loaded > > from the host, it sounds like you do need a property to differentiate > > between those cases. > Yep. > > > Is it sufficient to just set the firmware-name property for these cases? > > If the property exists, then you know you need to load firmware & what > > its name is. If it doesn't, then the firmware either isn't needed or > > will be automatically loaded from the external flash. > We have a default prefix firmware name(like himax_xxxx.bin) in the driver code. How do you intend generating the name of the firmware file? I assume the same firmware doesn't work on every IC, so you'll need to pick a different one depending on the compatible? > So we'll look for it when no-flash-flag is specified. In our experience, > forcing a prefix firmware name helps the user to aware what firmware > they are dealing with.
Attachment:
signature.asc
Description: PGP signature
