Messages in this thread | | | From | "Subhasish Ghosh" <> | Subject | Re: [PATCH v4 01/11] mfd: add pruss mfd driver. | Date | Wed, 4 May 2011 12:48:43 +0530 |
| |
Hi Arnd,
How about just doing something like:
#> echo da8xx_pruss_uart >> firmware.bin
i.e just append the device name (from the board file) into the firmware file.
In the driver probe, we can parse from the bottom, when it reaches "da8xx_pruss", the rest of the upper data is the firmware and from the full name, we can determine if it's a CAN, UART or any other peripheral.
So, based on the platform_data, which the MFD driver received, it can find out which device to initialize.
Also, does the line wrapping look any better ?
> On Thursday 28 April 2011 09:17:21 Subhasish Ghosh wrote: >> > >> > You can easily do that by adding a small header to the firmware >> > format and interpret that header by the MFD driver. When the name >> > of the subdevice is part of that header, the MFD driver does not >> > need to understand the difference, it can simply pass that on >> > when creating its child devices. >> >> I don't understand why loading the firmware should be done at the MFD >> driver. >> The user already specifies the device he/she wants to start on the PRU >> via >> modprobe. >> A driver can be inserted, which can download a printer firmware on one >> PRU >> and a >> scanner firmware on the other. This way both cores can be used for >> separate >> purposes. >> I mean, say in a real MFD controller, that will also have two separate >> cores >> running on it, >> just that, the firmware on it would not be downloaded runtime but fused >> in >> some non volatile memory. > > Then I must be misreading what your code currently does, because it does > not > match your explanations. What I see in the platform code is that you > create > MFD cells for specific devices that get automatically created by the MFD > driver. This will cause udev to load the drivers for these devices, which > then load the firmware they need. > > Also, I cannot see how the method you describe would make it possible to > the same driver into both units, e.g. when you want to have two serial > ports. The reason is that you currently hardcode the PRU number in the > driver and that you cannot load a single driver twice. > > Finally, I'm trying to make sure that whatever solution you come up with > will still work when we migrate the code to using a flattened device tree. > In that case, you would ideally put the device firmware into the device > tree as a property that matches whatever you have connected on the > specific > board (at least as an option, you can still fall back to > request_firmware). > You definitely want automatic module loading in that case. > > Note that using module loading with specific parameters in order to > match the hardware is not a recommended procedure any more. The code > really needs to work the same way when all drivers are built into the > kernel. It should not be hard to use the firmware loading mechanism > in the MFD driver to both load the firmware and configure the devices > appropriately so we always use the right driver for the currently > active devices. > > Arnd > > BTW, something is wrong with your email client line wrapping. I've fixed > this up manually before when replying, but please find a way to get this > right in the future.
| |