More importantly, reg-shift doesn't say what part of
the bigger words to access. A common example is byte-wide
registers on a 32-bit-only bus; it's about 50%-50% between
connecting the registers to the low byte vs. connecting it
to the byte with the lowest address.
We already have
Hello.
Segher Boessenkool wrote:
This doesn't mean that shift is better anyway. If everyone
considers it
better, I give up. But be warned that shift (stride) is not the only
property
characterizing register accesses -- the regs might be only accessible as
16/32-bit quantities, for
This doesn't mean that shift is better anyway. If everyone
considers it
better, I give up. But be warned that shift (stride) is not the only
property
characterizing register accesses -- the regs might be only accessible
as
16/32-bit quantities, for example (16-bit is a real world
On Wednesday 25 July 2007, Alan Cox wrote:
pata_platform and ide_platform are carrying same driver names,
to easily switch between these drivers, without need to touch
platform code.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
Hi,
On Wednesday 25 July 2007, Vitaly Bordug wrote:
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed from that driver. It's fine,
Hi,
On Thursday 26 July 2007, Guennadi Liakhovetski wrote:
On Wed, 25 Jul 2007, Alan Cox wrote:
driver to using platform-device. I got a reply, that it's not worth it
now
that IDE is slowly becoming obsolete, and the pata_platform serves the
perpose perfectly well. I found this
On Jul 25, 2007, at 11:53 AM, Vitaly Bordug wrote:
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed from that driver. It's fine,
since
Sergei Shtylyov wrote:
It doesn't buy us anything in here, but it's conceivable that someone
may want to write a driver that uses a shift in the I/O accessor
rather than an array of port offsets,
It wouldn't be IDE driver then, and neither it would be libata which
also does this
On Thu, 26 Jul 2007, Sergei Shtylyov wrote:
Guennadi Liakhovetski wrote:
Wrong list to submit sych stuff, post to linux-ide.
Not entirely. The patch (or other patches in the series) would also touch
ARM platforms in the mainline, currently using that driver. As I didn't
Was
On Wed, 25 Jul 2007, Sergei Shtylyov wrote:
Guennadi Liakhovetski wrote:
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed
Scott Wood wrote:
It doesn't buy us anything in here, but it's conceivable that someone
may want to write a driver that uses a shift in the I/O accessor
rather than an array of port offsets,
It wouldn't be IDE driver then, and neither it would be libata
which also does this another
Hello.
Scott Wood wrote:
+hwif-hw.io_ports[IDE_DATA_OFFSET] = port;
+
+port += (1 pdata-ioport_shift);
+for (i = IDE_ERROR_OFFSET; i = IDE_STATUS_OFFSET;
+ i++, port += (1 pdata-ioport_shift))
Looks like shift doesn't buy as anything, why not just use stride?
Vitaly Bordug wrote:
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed from that driver. It's fine,
since those were never used anyway.
13 matches
Mail list logo
